Off the top of my head, issues I've seen with systemd:
* At some point there was no way to say, "bring up this service once the network is up". I mean, there was technically a "network" target, but it considered "localhost" as a network. So if, say, you have automounted NFS, the automounter starts running before your main interface has DHCP. This setup been a widely-used configuration for decades; the systemd maintainers didn't care.
* At some point, if you typed "reboot ; exit" in an ssh session, the "reboot" would hard-kill your ssh session and your shell before the "exit" would be run; so your ssh connection would then hang until the machine came up again and refused a TCP resend request.
* The whole thing with systemd reading the kernel's command-line, deciding that "debug" was meant for it, and spamming the logs making it completely unable to boot; and forcing the kernel to introduce a work-around to hide "debug" from systemd.
* The whole interface renaming thing that's happening in Debian now; every time our project has upgraded our test systems from jessie to stretch, and then stretch to buster, we've had to spend dozens of man-hours figuring out why our network configurations aren't working.
The problem here isn't so much that there are these sorts of bugs; the problem is that there seems to be an attitude of, "Well my set-up works; yours doesn't matter." That's not the attitude such a core piece of infrastructure should have.
Compare this to Linus' nearly fanatical insistence that things in userspace should continue to work. If Lennart Pottering had the same attitude towards breaking existing systems that Linus has, systemd would probably be incredibly popular.