Init should be simple, secure, and get out of the way. It should not take over the system. We should not be forced to use an init that does.
This man said it best:
wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd
"
Init has one other job, which is to keep the process tables clean.
See, any process can create a copy of itself (called “forking” (don’t
laugh) in Unix terminology); this is usually a precursor to loading some
other program. Any process that runs to completion can deliver a status
code to the process that created it; the creating (or parent) process
is said to “wait” on the status code of the created (or child) process.
But what happens if the parent process dies before the child does? What
happens is that init is designated to be the adoptive parent of the
“orphaned” process, and it waits for, and discards, any status code that
may be returned by the orphan on exit. This is to prevent “zombie
processes” – process table slots that are filled with status codes but
have no running programs attached to them. They are undesirable because
they take up process table space that could be used by actual, running
programs.
So it is important that init run well and not crash.
Now, in Unix system design, it is a generally understood principle
that a big task not be handled by a big program, but rather a collection
of small programs, each tackling one specific, well-defined component
of the larger task. You often hear the phrase “do one thing, and do it
well” as a guiding principle for writing a Unix program. One major
reason for this is that a small program has fewer places for bugs to
hide than a big program does.
"