But if systemd was pid 1 and something killed it, you would have a kernel panic. How is that better than a system with a bunch of unmonitored processes? At least with the latter you can safely bring down the system, instead of having a hard crash.
It can crash due to bugs it can't handle, or it can voluntarily shut down.
Try it:
vidarh@opus:~$ sudo kill -9 1
[sudo] password for vidarh:
vidarh@opus:~$
No effect.
In the case of systemd, if it runs into a non-recoverable situation, crash() in core/main.c gets called, which then proceeds to try to create a core dump and spawn a shell as an absolute last resort to give an admin a chance to take corrective action, which is already a step up from your typical init assuming the manage to get the part of systemd that runs as pid 1 (by no means all of systemd runs as pid 1) as stable/bug-free as your usual init.
Of course there's an uncertainty there, and they'll have to prove they can keep that part rock solid or it'll be useless.
There are plenty of ways to kill pid 1. The major concern is simply software error, which is another reason why the current systemd design is poor. But if you'd like a concrete example, go ahead and attach gdb and use your imagination.
Sysv-init does not know what to do with those processes other than reap zombies.
Now you have a system full of unmonitored processes, just as without systemd, and no standardized way of restarting the services.
This is why systemd needs to run parts of its logic in pid 1 to be most compelling.
You can launch systemd without letting it be pid 1, but you lose functionality it can't provided outside it.