Yes, without question. Systemd provides me absolutely no benefit when running a server and adds considerable complexity and fragility in a critical component.
A traditional SysV init is just fine. Want orchestrated service invocation on startup? Run it from SysV init instead of replacing SysV init.
There is no need to conflate the "sysv rc system" with "sysv init." They are entirely separate things.
So you're saying to just use SysV init to launch processes from inittab, and have one of those processes be a systemd/launchd clone that launches everything else. I mean, I guess that's a possible design, but at that point I would question whether using the SysV init program is really buying you anything.
In any case, most people wouldn't consider that design "SysV init". The SysV init ecosystem is built around rc files.
I teach unix internals to engineers as part of my job and I've found most engineers aren't intimately familiar with the distinction between the RC system and the init system at all. I agree there isn't widespread understanding of this distinction but I think it is because most engineers simply don't know how any of this works.
The reason to keep these things modular is flexibility and ease of analysis and improvement. The major criticism I see with systemd is that has undefined operational scope and unbounded feature creep. It has no stable interface between components and changes behavior in incompatible and difficult to predict ways fairly regularly. From a systems perspective it's a big ball of mud and the lack of a formal interface makes it prohibitively difficult to change or replace its subsystems.
I don't like that systemd performs ANSI animations on my machine's serial console, for example. Have you seen the "marquee" animations it does when certain services start? I sure would like to force it to print sequential lines of text instead, but I can't.
I don't like that when systemd updated basic utilities like "reboot" I lost the ability to use them in a chroot. Even "reboot -f" which does not need to talk to init. I had to write my own one-liner to call reboot(2) myself not too long ago.
System components need to be well scoped and replaceable. There's a major design problem brewing in this area.
/sbin/init is pid=1, the single process that the kernel starts when a system boots. It typically runs a command to kick off bringing up userland to the correct runlevel, maybe something like "/etc/rc.d/rc 3". It doesn't do anything more than just execute this command.
The command is part of the RC system. Typically written in shell, it handles walking /etc/rc.*/ and running the scripts contained therein to configure and invoke the various services for a particular runlevel.
You can boot linux using your own init and skip the rc system. From grub, add "init=/bin/sh" to your kernel parameters and you will get a shell as pid=1 and no other processes -- from there you can run commands as you wish to bring your system the rest of the way up. If you were to run "/etc/rc.d/rc 3" by hand you would invoke the same scripts that normally run on bootup to runlevel 3.
You could also delete all these shell scripts and replace them with your own code for configuring the system.
It's not only possible, it is how the System Resource Controller worked in AIX from version 3.2 back in 1992 onwards. srcmstr is run from an entry in inittab, which at the same time shrank to just one run level in real use.
You have erroneously conflated rc and init, as others have pointed out.
A traditional SysV init is just fine. Want orchestrated service invocation on startup? Run it from SysV init instead of replacing SysV init.
There is no need to conflate the "sysv rc system" with "sysv init." They are entirely separate things.