There's a lot of negative PR and not much evidence of why people shouldn't use it. Comes across as like the same recommendations of "don't use chrome, use this fork instead", one that's run by a tiny team of people who face very little consequences for messing up.
* build system actively makes it difficult to build one component without the others, seemingly for political rather than technical reasons
* build system relies on Python, making bootstrapping more difficult (not quite desirable for "building blocks to build an OS from")
* needless overlap with countless other pre-existing projects including binfmt-support, lxc/runc, and libdbus
* cgroups2 hierarchy model which is unworkable for rootless containers unless they register with systemd via dbus or are running directly as systemd services
* The dependency model has lots of corner cases and gotchas. OpenRC and the LSB headers are much simpler and just as effective.
* Events are done in a hacky way: device events are performed by tucking "SYSTEMD_WANTS=..." away in a udev rule somewhere, IPC and timer events have their own unit types. This model is not extensible, and it obscures the policy rules that can be used to start a particular service.
* All the positive PR and marketing has left a bad taste in my mouth. Why did RedHat fly Lennart across the world dozens of times just to sell this hunk of C to literally anybody that would listen? It was a waste of petrol and shows that systemd did not win on merits alone.
* does not make any attempts at portability, and does not follow any pre-existing standardized interfaces that can be easily emulated on other OSs.
* Reliant on dbus as its primary IPC mechanism, when it does not even need a bus in the first place. JSON over a socket could have been a simpler and cleaner choice.
Many of those posts have been met with ignorance from the developers, even resorting to "it's not a bug" when it clearly is. Systemd has been pushed into distros based on improvement of boot times (their PR), not as a basis of a stable replacement of an init system. There were no problems of existing init systems to resolve, and SSD's have made the boot times pointless. My fully-loaded Devuan install boots 3 seconds quicker than Mint, Solus or Fedora.
Genuine outstanding issues highlighted in the forums are things like not being able to get unit files to start services at boot up, difficulty in finding start up errors due to the order of other services starting, errors not showing up in logs and untraceable boot delays. These are not made up, just take a look at forum threads tagged with systemd.
It has also become much more than an init system. This has resulted in bigger dependency issues, in turn resulting in not being able to install some applications purely because of a dependency on systemd somewhere down the chain. On non-systemd distros applications don't care which init system you use.
It's not negative PR, it's real users having real issues that have had something pushed on to them. For systemd's original portrayed purpose there is no reason devs couldn't have spent their time creating configuration utilities for the existing inits. At least when something breaks on the established ones, there is only an init system to look at.
"Systemd also provides a number of other executables (systemd-udevd, systemd-logind, systemd-resolved, systemd-networkd, systemd-tmpfiles, systemd-localed, systemd-machined, systemd-nspawn, etc.), libraries (libsystemd, libudev), a PAM module (pam_systemd.so) and a UEFI boot manager (systemd-boot), among other components. So any other package that needs any of these components, even if it is just one, would pull in THE WHOLE SYSTEMD PACKAGE as a dependency."