Maybe I am too much of a minimalist, but I think systemd is trying to solve a dependency problem that should not be as bad as it is.
# ps aux | wc | awk '{print $1}'
200 # ps aux | wc | awk '{print $1}'
200One of the headaches of the old SysV init system was you had specify what order daemons started and when they started in the boot process.
The login daemon started while the OS was still in single user mode. Then you'd start the logger. Now you bring up multiple users, and the network stack. Maybe NTP, DNS resolve,run as separately users? They definitely need system log.
Systemd you just state what your daemon already needs running and it'll on boot resolve the daemon start order.
If you've only ever lived in a package managed eco system and never rolled several of your own daemons you likely never encountered this issue.
The old Apache initscript (for just one egregious example) was a huge ball of shell script wizardry that checked all sort of things on startup, handled restarting/reloading based on the command and some other factors (graceful restart is only possible under some circumstances, etc.), kept up with PIDs, and cleanup. The systemd unit file for Apache is 17 lines long, minus comments; it is declarative, looks like every other unit file, and handles all the same stuff, and better than the old initscript. The complexity is gonna be there. These systems are complex and do complex things. it's just a question of what layer the complexity shows up in. systemd pushes it all down into systemd where most users and administrators and packagers and developers never have to see (much of) it.
And, as you note, run levels and process order are another layer of complexity pushed onto the administrators that could be pushed into the init, but never were under SysV initd. Again, it's handled by humans who have to have a lot of knowledge about the system, the service in question and its dependencies, in order to write the initscript and put it in the right place in the boot order...and there's room for mistakes. I've been packaging system level services long enough to have had many experiences getting it wrong in subtle ways.
Maybe I'm just getting old and grumpy. But I have a Linux 2.0 kernel machine that has been running a LAMP stack for over 10 years that boots in one tenth the time my Ubu 16.04 machines - that run the same LAMP stack - do.
Ah for the old and simple days...
Do try out FreeBSD then -- an OS for the old and grumpy. Systemd free. Uses an init system written in sh(1) that just works.
And yes, sysadmin will still need to tweak things, because a distribution maintainers cannot predict all the possible dependencies between services. One could never forsee that Mailman would fail to run when OpenLDAP was stopped, and this is what I had in one place.