then rejecting it requires a strong, rational argument - and even the best such arguments are likely to hold only in very rare niche cases.
There are quite a few reasons. For instance, like I already mentioned, sysv init has no logging and bad error handling. Processes may disappear without any logs being emitted. PID files may result in services not properly restarting. It's not a very reliable system, it's fragile and can break in ways that require you to manually do its job.
Consistency is not in any way enforced, for instance the S/K system means that changing from runlevel 1 to 2, and from 3 to 2 can result in different things running.
Performance can be much improved, because there's no parallel startup in many implementations and no on demand loading.
Processes are not tracked, if you see some mysterious process in the process list, the system doesn't help you figure out what service it belongs to. systemd uses cgroups and always knows what a process belongs to.
Things like CPU and memory limits have to be hacked in by hand, rather than being supported by the system itself.
And the problem with systemd is it violates virtually every one of the principles of that philosophy and offers NO rational reason for ANY of the violations - and it isn't doing so in a niche where perhaps some of those principles are genuinely not applicable, it's doing it to the heart of the system.
The sysv init reached the end of its life. There is a reason why Ubuntu, Apple and Solaris (which is by the way True Unix, which nevertheless decided that init scripts were getting rusty) moved on to better things. This isn't even new, it's been coming for ages. Dependency systems and parallel boot have long been a feature added on top of sysv init in Linux distros, but it rarely worked perfectly.
Why do you think it took them 20 years to implement the bare beginnings of proper multi-user support ? Because the policy of single user was tied fundamentally into the mechanisms of the system 20 years earlier.
Unix wouldn't have fared much better if it didn't have multiuser from the start. It's a fundamental part of the API, you can't just graft on multiuser to something that didn't have it before. Take for example that on a multiuser system there are access restrictions. An application made for an initially single user system will often poke to deep into where a multiuser system can't allow it to, and a flexible policy isn't going to save you from that.
It violates the rule that applications should always expect simple clear text as input, and produce simple clear text as output. That rule is so fundamental to the flexibility and power of unix that to break it at the init level is to completely destroy that power. If systemd becomes universal, linux will lose all the marketshare it gain in every market, and lose it to unix systems that kept the rule - because the next breakthrough in technology will require adaptations - which systemd will have made incredibly hard.
Hah. Linux lost market share to OS X, which by the way has a very systemd-like service system. Interestingly nobody seems to have got turned off by that.
More-over, it weakens what you can do with the system - the ability to string commands together in utterly arbitrary ways via pipelines have allowed a relatively small set of primitive applications to serve literally ever conceivable user need, exactly by NOT trying to conceive of every possible user need - but providing the means to construct whatever solution you could possibly want on the fly.
Um, systemd isn't about to take over the commandline. Pipes still exist, you know.
In fact, systemd makes it easier to string stuff together. You can trivially make even a single line script into a systemd service in about a minute. sysv init is rather more involved.