On some level I agree with you, but if you look at the things that Apple is able to do with OS X and timer coalescing [1], that central point of coordination becomes critical. You need a mechanism for starting and stopping all things, not just daemons, that plays by a specific, defined set of rules so you don't have multiple processes trying to do the same thing.

On another level, I feel the "unix philosophy" of having a lot of interchangeable modules taking care of small, simple tasks hurt it: each level of abstraction has a performance hit, and having to support multiple components in a modular way makes change management a nightmare. There's something to be said for the elegance of tightly integrated components: you can make assumptions that you couldn't otherwise make in a more modular system. I can see how it would be a problem if systemd were proprietary, but it's open source.

[1] http://www.apple.com/osx/advanced-technologies/

No. No, no, no.

For all other processes except pid 1, the status of processes in the system is in a state of Heisenbergian uncertainty because any process could die and have its pid taken by something completely different between the time you query the process table and the time you take action. So if you want sophisticated monitoring and control of all the processes in the system (and you almost certainly do), it should be done in pid 1.

The minimalist init is neckbeard-compliant, but it's just not enough for a robust modern system. Systemd is the correct design.