None of these even want to include support for features found in the Linux kernel, so that they work can work on all Unix systems out there.
I’m assuming you meant to say that “none of these are sacrificing portability for features”? If so, absolutely, and that’s very much a feature, not a bug. Portability matters.
So none offers similar features to lock down services out of the box, as those rely on Linux specific kernel features.
If using Linux specific features was the only approach to security, I wonder how OpenBSD exists.
Of course you can hack that into the init scripts somehow. Sysv-init has shown how well that worked cross-distribution.
That’s a bit disingenuous. SysV Init has long term glaring, unrelated issues. It is really showing its age.
Systemd moved the goal posts for what a Linux init system needs to do.
On that, I very much agree. Moving the goal posts doesn’t mean “doing the right thing”, however, and this fact is a big part of the reason some people complain about it.
I doubt any generic Unix init system can compete.
With the feature set? Absolutely not, you are correct. But the same way, systemd cannot compete with their simplicity, maintainability, smaller attack surface, and the list goes on and on and on.
So in the end, it is down to your personal preferences.
Which is theoretically all fine; but practically, it stops being “all fine”, for some people, when you consider systemd’s aggressive disregard to being compatible with literally anything else.
The systemd project is the software embodiment of the “this works and it works well, so why would you ever need anything else?!” mentality.
People take issue with the facts that “aggressive disregard to being compatible with literally anything else” reasonably translates to “having absolutely zero room for mistakes” (which, to be clear, systemd failed to honor multiple times: it isn’t perfect, which would be fine, in a vacuum, but not with this mentality) and that “works well” varies drastically from case to case, and from expectation to expectation (in short, it does not, always, “work well” for everyone and/or in every use case).
TL;DR: systemd existing is totally fine, systemd being used by the majority is totally fine. systemd de-facto causing other projects to put in (sometimes radically) more work than they should have to, is not okay; and systemd de-facto making itself irreplaceable on the grounds that “it’s fine, don’t worry about it”, is not okay.