Design choices are fine - I can understand why systemd takes a different approach.
What I don't like, and completely disagree with, is systemd not working with the community they directly effect to reduce disruption.
Like it or not, the product is an industry standard, and so will be held to industry expectations.
Rather than turning around and requiring everyone to change, they could have said, "Sorry, we're making changes, here are some preliminary patches that could help."
Or a timeline for a breaking change, wherein they can negotiate with others.
I don't have significant issues with systemd's software, though some reservations about quality. My main concern, and it has been since the beginning, is that systemd acts without thought or conscience to the effects that they might cause.
They lack the ability to be a team player, despite creating an environment where people depend on them.
systemd's adoption rates is an absolute credit to it. They have some very good design thoughts, and those working on it have done some excellent work.
However, it would be better if they communicated with the people they effect, rather than letting the community be an accidental Q&A team when things go wrong.
They do get this right sometimes, but that seems to be the exception, rather than the rule.
They approached the init.d situation calmly, and slowly. They worked with Debian, and Fedora and others to make sure it would work without interruption or loss of quality.
They approached the sigkill situation like they were a kid who just learned how to light a fire and wanted to burn the library down.