Go look up how old SysV init scripts are, and then ask yourself if those decades count as "any time soon" from when it was adopted. It is silly to start the measurement now, after decades of sysadmins complaining about the poor feature set. You spend decades being told, "we'll have something better someday" and then when it finally arrives and works and does all the stuff that sysadmins wanted (cgroups, better logging, etc) then people are worrying if it is too "soon." Well geeeeeeeeeee, why wouldnn't it be late? Seems like a fake complaint to me. Not sure how you can compare it to cars with joysticks, which drivers haven't been asking for.
Also, it is very telling about your attitude that instead of addressing what sysadmins say is good about systemd, you just call it names like "octopus." Yes, I'll agree they didn't request any of the features using pejoratives. People who value a feature set usually discuss it using real terms. So the feature requests are not "octopus" but "modular centralized logging" and "better process groups" and "parallel service startup" and "effective service dependencies." All of these things are directly related to what SysV init does too. Just because it is less effective at them, you count it as doing one thing. Except there is more than one thing that has to happen right there, and SysV init does more than one thing too.
The KISS argument is especially daft. How is a mishmash pile of init and scripts and logging somehow more simple? Every part is complicated because it is a giant "pile." And process management is complicated with SysV by the complete lack of needed security and management features. cgroups reduces overall system complexity by providing a means of managing process groups. cgroups are a new feature in the linux kernel. It exists for real reasons. I guess you think it would reduce complexity and keep it simple to just tack on cgroups to what SysV init already did, right? Oh, wait, you only want it to do strictly one thing. Except it already does more than one. So just, no cgroups, right?
None of your complaints are actual problems with systemd. It is just repeated propaganda. And nobody using a software package cares if you don't need all the features, like faster boot time. Isn't it rather freakin' obvious that that is a feature that is going to be valuable for many use cases? You don't have that use case, fine. And if you did, would you still be against software that provides it?
You really think systemd makes it so humans can't troubleshoot? Wow, those sysadmins celebrating it must be alien superheros. Oh, wait, no. We're humaans after all. Trust me, humans without an irrational hatred of systemd have no trouble at all troubleshooting it. There are even cheat sheets that map the old commands, to the new equivalent ones. It would be a funny set of arguments to listen to if somebody claimed that youngsters who learn on systemd would have an easy time troubleshooting an old SysV box, based on this claim that SysV is more amenable to human troubleshooting. I guess you'd have to resort to comparisons that claim that SysV is even easier than DOS, because learning bash scripting and the standard SysV sh libraries is so much easier than learning that an .ini file has sections.