I'm not on either side, but I appreciate the way some complexity is dealt with simple little things. So elegantly solving problems: https://www.youtube.com/watch?v=S0mviKhVmBI#t=450
The entire systemd debate is as bad as it is because this is a can that has been kicked down the road for two decades because nobody wanted to have the same argument again. Everyone has known for a long time that at some level, Linux needed better coordination between user applications, hardware, and system services. systemd seems to deliver on most of the functional requirements of such a system, though the implementation method has upset some people on a philosophical level because they believe it's counter to the Unix way, whatever that means.
I would argue that software development in general has drifted away from "the Unix way". Modern software development is a mess of dependencies, abstraction layers, control points and dominant standards controlled by individuals/companies with a vested interest. Linux is a good counterbalance to that, but at the same time it can't stray too far away from the way that people use systems or it becomes too outdated to matter. Is systemd the answer? Who knows. But in the absence of something that performs its function, companies will step up with proprietary solutions for their use cases (launchd on OS X/iOS, whatever Android uses) that lead to more walled gardens, not less.
People like the whipupitude, because they know it. But nearly every init.d script I've read has bugs. There isn't a testing framework to ensure correctness and even if there were it would be needlessly complex because you'd spend a bunch of time mocking out the filesystem / the process table / whatever else init scripts do.
We know what initialising a process should look like and we should be stabilising this API so that we limit mistakes/bugs.
Plan9 seems to have better distilled and refined the "unix way". But it's been too little too late and I'm sure if it became popular there's be wars about it too.