To fully understand the problems with systemd, you need to understand some basic tenets of modern software development:
* Single Responsibility principle: Each piece of software should do one thing well, rather than multiple things poorly.
* Keep It Simple principle: Each piece of software should be as simple as possible, though no simpler.
* Reuse: All functionality common to multiple pieces of software should be its own piece of software.
* Dependency Management: All software should explicitly list the specific versions of its dependencies; all software should avoid unnecessary breakage between updates.
* Communications: Be strict in what you send (follow agreed protocols, APIs, etc.). Be liberal in what you accept. (As long as input is unambiguous and sufficient, accept it, even if it contains information you did not expect.)
* Use versioning, including semantic versioning where appropriate.
* Don't gratuitously replace working and tested code without a good reason. Don't re-invent a perfect wheel to make a potentially crappy one.
* Design and build a system in such a way that testing of each piece as well as each business requirement can be automated.
* Security. Minimize potential attack surfaces. Use the safest languages, code, constructs, system calls, etc., possible.
OK, so these are just a few things we developers try to keep in mind at all times.
Lennart Poettering is not a dumb guy, and he has had some good ideas at times.
However, systemd disregards many of these very core principles. Often gratuitously so.
While initially sold as a replacement init system, which for sure is needed for some use cases, it has morphed to become a large and growing part of Linux user space.
The entire Internet was almost brought down a couple weeks ago because of an exploit involving, though not directly caused, by systemd.
There will be more such exploits, and systemd provides a HUGE attack surface because of its unique status as the process that starts, stops, logs, and monitors all of the others.
Nontechnical end users, and distribution maintainers, are generally OK with all of the above because of the fact that it makes many parts of their lives easier.
But software developers such as myself understand the risks, and many, including me, find them unacceptable.