Many of the problems with sysvinit have been solved in OpenRC. For example, OpenRC uses dependencies to define the order in which the services are started. My point is that such a radical change as systemd is not required to deal with many of the issues in sysvinit.
Systemd is not just about the init system. It's about complete system management from hardware, services, logins, and amongst that also the init system.
Standard systemd supporter response. "we should systemd because it will fix all the problems in sysvinit .... what's that, they are fixed in OpenRC ... don't look at sysvinit .. look at the shiny over here instead". The point is that a major plank of the argument of systemd is about sysvinit and it simply isn't valid.
Before I talk about why restarting services would be a good idea I should mention to you that this is configurable. Not just configurable, but highly configurable. You can opt to restart a service based on the exact exit code of the process.
Again, you missed my central point. The value is being able to restart services automatically is exceedingly low. Processes don't die on my servers and if they do, it needs human involvement to investigate.
Let me stop you there for the first part. There is NOT VERY MUCH RUNNING AS PID1. The core systemd process exists pretty much only to catch orphans and start up some of the 70+ other systemd functions
As you point out, the very services that are replacing much of the functionality in those init scripts are running as PID 1, so your argument is irrelevant. Just because not much is running as PID 1 does mean that nothing is running as PID 1.
I would like to point out again, 200 lines to start sshd on my system.
On my Gentoo system, running OpenRC the init file for sshd is 87 lines, of which 13 are blank, and 4 more are comments. So, really 70 lines. Furthermore, those init scripts don't change much -- any bugs will have been worked out. Because systemd centralizes this, the code will change all the time.