Except, not many people are as smart as djb. But, djb being smart doesn't automatically make his tools good ideas to use (I'm looking at you, Mr. "I made my own register allocator because I don't trust compilers").
djb lives in a quaint fantasy toy land where he gets to write whatever he wants and doesn't have to interface with real world systems at scale. That's great when you're the author. Your software can be clean if you only write for yourself and not for 50 million other programmers trying to build software on top of your tools as well. But, it's painful when you're a user and real world problems get ignored because the author just never experiences your same problems (so they never care to fix them).
Much like how a startup isn't 90% code and 10% "company," public software in 2015 shouldn't be 100% writing code all day then dropping .tar.gz files on a server once every two years while ignoring wider principles of project governance, collaboration, and feedback/growth processes.
Bernsteins programs are definitively a bit... different. For some reason the way you use/administer them always seems more sensible to me. I believe that many of the complaint people have is a reflection of configuration being different from what they'd expect.
Publicfile and ucspi-tcp might not work "at scale", but qmail, ezmlm, djbdns and daemon-tools certainly work even for very large deployments. I would agree that qmail and ezmlm benefits from the patch-set floating around.
In practice, you'd be using one of the many successors to djbware today, not the direct originals. You'd install runit, s6 or daemontools-encore rather than plain daemontools. They all reuse the same libdjb interfaces and follow the same code style, otherwise functionally they're supersets.
I use void linux (http://voidlinux.eu) on my laptop and vps, which uses runit as its init system, and it's beautiful. It's such an elegant system. Writing the run scripts is so easy, and there's so little you need to understand to do it.
Rather than learning how upstart or systemd unit files work and learning their configuration languages, you only need to know how to start a process that runs in the foreground and logs to stdout.
Learning the language is only necessary because some services are more complex. For example, if you need your process to only start after another, you must now learn the syntax of runit's sv program.
In 2015 open source software development is 90% about doing peripheral work, sit in committees of various foundations, force people to use a different infrastructure every two years, and generally, avoiding real work as much as possible.
djb lives in a quaint fantasy toy land where he gets to write whatever he wants and doesn't have to interface with real world systems at scale. That's great when you're the author. Your software can be clean if you only write for yourself and not for 50 million other programmers trying to build software on top of your tools as well. But, it's painful when you're a user and real world problems get ignored because the author just never experiences your same problems (so they never care to fix them).
Much like how a startup isn't 90% code and 10% "company," public software in 2015 shouldn't be 100% writing code all day then dropping .tar.gz files on a server once every two years while ignoring wider principles of project governance, collaboration, and feedback/growth processes.