SystemD - A Necessary Evil
SystemD is bringing some very much needed structure to the Linux ecosystem. It simply isn't possible for an independent developer to write quality software for Linux as a whole, and a big part of that is the complete mish-mash of locations and multiple ways of doing things which have accreted over decades.
The biggest problem is the use of scripts - this is the whole reason ShellShock was possible - we have ad-hoc languages performing crucial system-administration and configuration tasks - a shell script is a completely unverifiable, obscure, and inefficient way to bind services and components.
For software developers targeting linux who are trying to write stable and secure software, the OS is a non-deterministic mess. We absolutely require the ability to mechanically generate scripts based on a given configuration and know that the system will take that form always, not 'sometimes'. The way forward for large system configuration is to use small domain-specific languages to configure and assemble systems. Shell scripts will never get us there, so there will be a transition that will annoy people that have a lot of time invested in learning shell scripting.
SystemD code is clean, very readable, and, yes, opinionated - but its opinions make sense - many of us don't want to be sys-admins, we want to get work done and the OS is just a component of our system. Documentation is an area that needs to be improved, right now to learn SystemD you have to go through a mess of blog posts on Poettering's site, and he for some reason has a robots.txt so the docs can't even be indexed. Other than that, the adoption rate speaks for itself, SystemD is addressing a need that nobody else has been able to fix.