Systemd is a big rewrite of some core components of a Linux-based OS. I did not like its design, its code and the controversy around it. But it was adopted by major distributions anyway and I have accepted it. Until came the point in time in which I started to use it.
Systemd is very opinionated. It made so many trivial tasks impossible that I am surprised it got thus far.
For example, systemd disallows any environment variables to be present in the main service executable path. But that is a huge problem for Java, as it normal to define JAVA_HOME variable and use it to find the executable. It is also forbidden to use symlinks in units, preventing another customary way - /usr/bin/java - from being useful in systemd world. As a result, we end up with the main executable being a script, which finds the current java and executes it. Is it any better than SysV scripts? Not at all.
The fear of symlinks goes even deeper in systemd, breaking the most unexpected parts of functionality. For example, it is possible to install your unit as symlink to a file. If you do that, start, stop, status and many other systemd commands will work. While enable and disable will not. The bug was reported and closed as WONTFIX with an explanation that unit files being symlinks is prohibited in systemd. But why other commands work, you may ask? Just for lulz, it seems.
I can say from experience now - systemd is terrible. I may go further listing all of its design and implementation flaws, and may even not talk about all the security flaws or hilarious bugs it has. There is enough to keep me going for hours.
Systemd only supports a tiny portion of real world use cases and violently rejects everything else. Like the famous refusal to add any support for HDDs (entire systemd team is using SSDs and they have nowhere to test - so lets forget that HDDs exist).
Even when some desired behaviour is documented it is often butchered in the implementation. Such as the case where the presence of both systemd unit and SysV script files at the same time on the same OS leads to systemd using its unit and ignoring the SysV file. It is a proper design solution. But the way it works... Upon initialization the utility notices a SysV file and attempts to create a temporary in-memory unit file for that, which fails because a permanent unit file for this service already exists. It causes the utility to spit a ton of errors and scary looking messages. It all works as described in the design doc, but not because somebody coded up to the spec, but because a bug in the utility causes the exact same behaviour as the desired one.
I will keep using systemd for the time being and will continue to support my end users who are on systemd. But I am sure it will be deemed a huge mistake in relatively short order.