I'm practically ecstatic about pkgng for one huge reason: no more waiting for ports to compile. Having source-based ports is all fine and well but all that time compiling ports is subtracted from the time the server(s) would perform some actually useful work. After all, servers exist to do some work, not to be waited on while compiling. The same goes for me: I don't want to wait for ports anymore.
I'm happy to say that pkgng pretty seamlessly interacts with the classical ports tree (by adding WITH_PKGNG=1 in /etc/make.conf). I can use most of the pre-built packages, but there are some ports which I absolutely need to compile with non-default options, and those I can compile and install the old-fashioned way. Such ports will automagically be registered with the pkgng package database.
This works until there's a need to upgrade such a port, and I don't really know right now how it will behave in the future. I suspect I will have to be very careful not to upgrade my manually-compiled ports with the default ones.
The recursive upgrade mechanism of pkgng is very powerful and really helps a lot. I had a machine which hasn't really been maintained for years, and I easily converted it to pkgng (using pkg2ng) and used the pkgng's dependancy and recursive upgrade algorithms to install new versions of packages. This worked mostly seamlessly, but there are some corner-case combinations of port/package versions between the "old way" of doing things and the "new way" which slightly confuse pkgng and require manual intervention by removing the old package and installing a new version of it.
There is also the case of replacing a package with another one, which is most recently exposed in the pkg-config <-> pkgconfig fuckup (and yes, it cannot be denied that whole transition was generally a major fuckup regardless of pkgng), which needs to be done manually with "pkg set -o devel/pkg-config:devel/pkgconf ; pkg install -fR pkgconf".
The only major shortcomings of pkgng can be traced to the way ports themselves work. Because they lack the Debian's intelligent "provides/depends/replaces" mechanism for package relationships, it is, for example, practically impossible to install a fcgid-based PHP stack with Apache-worker right now purely with pkgng (but on the other hand it's trivial to do it with lighttpd and other web servers with built-in fastcgi modules). The dependancies are rigid and every Apache module, including mod_fcgid, depends on the default apache package, with its prefork MPM. This can be solved e.g. by installing the apache-worker package and then manually compiling the www/mod_fcgid port. There are numerous other examples of such situations, but they will have to be solved at their roots: the ports tree.