The first problem I notice with sysvinit is that it is not a (single) initialization system.
Or, that may be the only problem, other than that it is a feature rather than a problem to those who understand the issues involved, whereas it is perceived as a problem by those who expect a system.
Attempting to unpack that a little, I do remember a time when I was looking for some centralized way to control what was being started when, and being a little stressed out to discover I would have to learn sh for real if I wanted to play with what boots up when. And then I would have to read and understand the programs -- scripts -- being used to get everything started.
And one of the distressing elements it all was the ad-hoc nature of the collection of init scripts. The only thing systematic about any of it was the loose framework of runlevels and the method of controlling boot order by tagging a script's filename with a priority number and then trusted the collating order. Which felt a lot like line numbers in basic programs, plus some extra chances for confusing oneself.
It took me several years (and playing with MSWindows's Wrong Way To Get It Right) to see that ad-hoc nature of sysvinit was, indeed, a feature, not a bug.
Sysvinit has been evolving, so that certain common features of services could be accessed through more central tools -- chkconfig and such. Also, the nomenclature has evolved quite a bit, so that, when you read the documentation for one set of daemons and pick up the documentation for another, you don't tend to be as lost at first. Likewise, the structure of the scripts.
What I want to see, rather than the implementation of a system where a system doesn't belong, is more evolution of the sysvinit set of systems, more cooperation between the teams working on the various services/daemons, so that methods of communicating dependencies and status information can be made more regular.
Systemd does seem to provide a forum for such communication, but I question the cost of the forum -- abandoning the ad-hoc, flexible nature of sysvinit for the confined, and confining vision of a small group of engineers whose (there's no way to avoid saying this) egos exceed both their experience and their vision.
Sometimes, no, often in engineering fields, an inexperienced engineer has been able to clear the air of irrelevant arguments and provide a catalyst for real solutions when the experienced engineers have been blinded by their experiences. And the new solution solves things.
I see some catalyzation of new approaches and such, but my present impression of systemd is that it is heading away from the solution, seeking the illusion of a solution found in Microsoft's stuff.
However, I can hope that the experiment with systemd, after having run its course, might provide us with more tools to return (yet again) to a more organized and accessible sysvinit.
The point of this ramble is what? I'm not sure. But, rather than rant about how stupid systemd is, perhaps we can get a working group or two set up to figure out how daemons and their packages should communicate their dependencies and status with each other? Then we could really solve the problem systemd is not solving right now, and either fix systemd or discard it as necessary.