I've managed Linux systems of all sizes and don't really get it either. Systemd is largely a good thing, though there are occasionally bugs that make if frustrating to deal with.
It's those bugs and weird cases (and the fact that -IME- systemd provides zero diagnostic help when you hit them) that are the killer.
In my professional experience, I've come to understand that the systemd project has an assload of accidental complexity that the systemd folks are unwilling to reduce. At least once a year, we'll have a production-down page from a customer whose root cause turns out to be systemd failing in some bizarre and entirely inscrutable way. After a ton of digging, we'll eventually find someone who has run into something similar, and either got no response, or a "Wow, that's weird. Well, there's nothing WE can or should do." response from the systemd people.
"Solving" these issues is very frustrating, because we usually end up changing things from one way that the docs indicated would work just fine, to a different way the docs indicate would work just fine... which doesn't give us any confidence that what we did won't suddenly stop working next year. A project that is as fundamental as systemd wants to be really should be aggressively reducing complexity to the minimum required to get the job done and regularly documenting caveats and quirks as they're discovered and deemed "E_WONTFIX".