What I don't understand is why systemd advocates continue to not understand the perspective of those against it. Critics tend to recognize what systemd brings to the table and debate from that point. Advocates just call those people idiots, curmudgeons, and so on rather than understanding the perspective of the opposing viewpoint. It's quite maddening.
Init runs as PID 1. Systemd runs as PID 1.
Most init systems have a negligible amount of code running as pid 1, meaning init itself is unlikely to ever cause a blip at runtime. The complaint is what the implication for the complexity and volume of code in systemd approach. A better counter argument would be that the kernel itself has even more complex needs and runs in an equally critical context. That's a bit more defensible, though adding more complexity under that excuse is still a weak one.
Claiming that "lots of people don't like systemd equates to anything other than lots of people don't understand systemd, but will complain anyway is just stupid
No, lot's of people who know well enough how systemd works and still don't like it for valid reasons. No one claims it is not capable of things that classic init could not really do, but the question is the relative value of those features and what is given up in the pursuit of those capabilities. systemd is more monolithic in design, involves more compiled code beyond the reach of the typical shell capabilities of a sysadmin, and is more complex in its underpinnings in general. If your boot went off the rails in a classic init system, you can work through it using shell debug because it is comprised of a tiny bit of c code that hasn't changed in an eternity jumping into a sea of plain old shell scripts.. You can chroot and play around a non-booting image if needed. If systemd goes off the rails, it requires a much more complicated debug effort. You pretty much have to start up a container rather than just chroot (admittedly systemd provides a facility to mitigate the complexity of that task, but it is more complex than just chroot). It has a high likelihood of landing in some code a sysadmin is helpless in the face of compared to the same task in classic init scripts. A local mistake can escalate to systemd debug assistance more quickly. This is very much like Windows (which has it's qualities as well) where if things go off the rails very far, it's nearly a lost cause to sort out what happened and how to come back from it unless you have Microsoft developers ready to answer the call to debug it (and they almost never are).
Some people don't like them new fangled fuel injectors and still think a carburetor is the way to go as well.
And there are tons of carburetor platforms in the wild for brand new products. Try finding a leaf blower with fuel injection. The cost and complexity of a fuel injection system is too high in many applications. If cost and complexity were equal, then *everything* would be fuel injected, but cost and complexity are not equal. This is actually a very good analogy for systemd, capable of inarguably fancier tricks but the universe of mechanics who can repair it when broken versus throwing the whole thing out is much different. The relative merit though is more questionable (everyone benefits from lower fuel consumption and reduced uncombusted gasoline in the atmosphere, not everyone really benefits meaningfully from the advances in systemd).
What systemd advocates fail to recognize is that not everyone should have to be an application developer to administer systems. They assume minor configuration mistakes are all sysadmins have to contend with and thus they don't understand why a sysadmin might need to follow the flow of the init system in more detail and yet not have the ability to easily cope with systemd code. The 'DevOps' buzzword may embolden assumptions in some circles, but it does not mean that good sys admins have magically changed, just that buzzwords have come to recognize how a good system admin has gotten his job done all along.
Yes systemd more thoroughly captures a child daemon into a cgroup. Yes systemd can do faster boot through avoiding the start of relatively expensive script interpreters repeatedly and also making services boot in a fashion. Yes journald files can more quickly accommodate more complex searches against the data. Critics don't say this is inaccurate, they say usually it is worthwhile or could have been done with a better design to cater to the sensibilities of those who really need to be able to handle unfortunate bootup scenarios as well as they can today without becoming systemd specialitsts.