>>20There are a few things about systemd's design goals that mean it ends up touching a lot of kernel interfaces. These are
1. The ability track a daemon's status after they are started, irrespective of whether the daemon spawns children and / or dies
2. The ability to start daemons in response to socket activity (like xinetd)
3. The ability to start daemons that depend on other daemons in a race-free way
If you do away with some of these you can potentially produce a simpler init system, but that just pushes the problem somewhere else. sysvinit did this and the result was init scripts with crazy things like sleeping for random intervals to give daemons time to start up.