What about daemons?

In my opinion, it is an illusion that starting a daemon up with CAP_NET_BIND_SERVICE improves security vs. having it start as root, create a PID file, acquire the socket, maybe go into a chroot jail, and drop to a non-root user. The opposite is true: if we only grant this one capability, the daemon does not know to and is likely "not privileged" to drop the capability, so it retains it for its lifetime (thereby letting a possible intruder impersonate services on _other_ privileged ports as well). It is not able to chroot() itself. It has to write its PID file as the non-root user and in a directory writable by the user (or it has to rewrite a pre-created PID file in-place, which has its own issues) - and then what, our startup scripts access that file as root and trust the PID found in there, thereby risking a root compromise via hostile file metadata or contents? OK, the scripts may be taught to switch to the same pseudo-user before accessing the file and signaling the process, but that's extra complexity. My estimate/experience is that most packagers and sysadmins get it wrong, even without the capability complication. Yet with properly written daemons there's simply no reason to do things in that complicated way.

Use of capabilities by daemon processes themselves, after they were started as root, makes more sense to me - e.g., vsftpd and BIND 9 do that.