Pluses:

Fast, probably the fastest build system there is after a hand-coded Makefile. MD5 sums are clearly not the bottleneck in SCons, and it is a fundamental design problem there.

Waf uses Python. This means that you can use all the right idioms for lists of things, loops, etc.

Not just a Make-clone, waf has build-system features. For example, it can check for headers, libraries, use pkg-config, has cross-compilation support, can create distributions, etc. Waf has separate configure and build steps too - in SCons if you use the autoconf-like features, they are checked every time you build (albeit cached).

Waf by default does an out of source build. This is also a minus though, as it is only available as a sub-directory of the source directory. You cannot build a single source from read-only media on various platforms, as waf wants to write files below the source tree whatever you do.

Intra-project dependencies are easy to use. Convenience-style libraries add the right -L and -I values to executables that use them.

File globbing works well. It isn't like CMake where using FILE(GLOB *.c) has a bunch of caveats.

Minuses

Waf uses Python. This means you have to quote everything. In make or CMake, it's main.c. In Waf (and SCons) you have to write "main.c". Similarly for command line arguments and so on. Being a proper programming language means you can "over-engineer" the build system, ending up with something that is perhaps well-written, but far more difficult to follow that the equivalent almost-declarative CMake input file.

Writing your own tools to process types of inputs that are not supported by default seemed tougher to me than with SCons or with CMake. Waf uses Python decorators to add methods to the default build context, which are then executed depending on the decorator-filters for the types of file in question. It is an elegant solution, but in practice too magical and it is tricky to debug.

Waf is really unstable (in the sense that it changes regularly, not that it crashes). The API changes every release, features are removed and deprecation warnings are rare. So if you hit a bug that gets fixed in a newer version and want to upgrade, chances are that your wscript file will no longer work. You are encouraged to ship a Waf binary-blob version with your source, similar to the configure "shell-blob" I guess, so if you can work around any bugs or live without newer features and stick to a specific version then this may be less of an issue.

There are warts in the API - sub_options vs sub_config vs add_subdirs to recurse directories, variable and function names randomly shortened (blddir, env, add_post_fun, uselib), having to pass an argument 'features="cc cprogram"' to compile an executable vs a dedicated cprogram method.... Version 1.6 will address most of these, but again you face the upgrade issue then.

Conclusion

I would use CMake for new stuff. It is not as cool, doesn't have an uninstall target, but is more compatible with people's expectations (the way an out of source build works, for example), has code coverage, unit tests, as well as being tested on more platforms. It's language is easy to learn - there is only COMMAND(arguments) - and the build scripts you write are generally "brain dead", it's impossible to write code that is difficult to follow. You can tell it has been used by more people and has a lot of the wonky parts hammered out.