The reason abstract-namespace sockets are evil is that everything you end up wanting to do to them has to be reinvented, or else you live without. If on the other hand you use a common abstraction, namely the filesystem, then you get the benefit of all the common tools.
Cyberax's examples of the things you want to do include
* protect with AppArmor
* hide in a namespace away from some processes (like with chroot)
* see when they were created (presumably for debugging)
Here's my example:
* move them out of the way.
You think you wouldn't want that for a socket? Think again. I once had to deal with a buggy server process (clvmd) that would occasionally hang unkillably (due to a kernel bug), while holding an abstract-namespace socket. This means that when I tried to restart it, the new process would immediately fail because the socket was already bound.
If the clvmd authors had used filesystem sockets like good Unix-respecting developers, I could have simply mv'd or even rm'd the old socket, and the new process would have been free to bind to its socket at the usual name. Instead, I had to restart the box. This was a VM server -- dozens of people's VMs were affected by each restart. The bug recurred a couple of times a day. I *really* wished the program had used sockets in the filesystem, or that somebody had implemented rename() or unlink() for abstract-namespace sockets -- but who would do that? The program should have used sockets in the filesystem.
If you're unhappy because a system leaves files around in /tmp that aren't used anymore, you're really focusing on the wrong things.