Are they ? Because all of that looks like posturing on principles.
Like, I have plenty of issues with systemd but still on span of 461 systems we manage (mostly Debian with some centos here and there) with variety of use cases (from "legacy" to k8s running on ceph cluster) it saved us tens of thousands lines of code and allowed some tricky use cases to be far more reliable than before.
Because apparently despise vehement claims sysV scripts are "simple" and "straightforward" it turns out there is plenty of edge cases that most developers don't fix in those scripts.
For example the fact doing start -> status immediately after in many Java apps will tell you your application is not running, because developer delegated Java app to write its own pid file and that takes time for JVM to start. So if something like Pacemaker does exactly that (start app, wait for start script to finish, run status, Pacemaker thinks app didn't start and fails the service).
Why do systemd proponents always compare it to SysVinit?
Compare it to Runit (Void Linux, antiX, Devuan package, as well as packages for all BSDs), OpenRC (Alpine, Gentoo, Devuan package, compatible with FreeBSD and NetBSD), … with S6, which many folks (including me) do use on their Linux and BSD systems.
I, too, operate a fleet of servers without any trouble using Runit and OpenRC.
Especially if the 6 users are completely happy with it, then that is validation that it has a solid use-case. It means there are possibly many more who would use it, just that they've not heard about it yet.
Like, I have plenty of issues with systemd but still on span of 461 systems we manage (mostly Debian with some centos here and there) with variety of use cases (from "legacy" to k8s running on ceph cluster) it saved us tens of thousands lines of code and allowed some tricky use cases to be far more reliable than before.
Because apparently despise vehement claims sysV scripts are "simple" and "straightforward" it turns out there is plenty of edge cases that most developers don't fix in those scripts.
For example the fact doing start -> status immediately after in many Java apps will tell you your application is not running, because developer delegated Java app to write its own pid file and that takes time for JVM to start. So if something like Pacemaker does exactly that (start app, wait for start script to finish, run status, Pacemaker thinks app didn't start and fails the service).