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.
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.