I'm not a massive fun of systemd, I find that the unit files myriad of options difficult to remember and despite the documentation it is often hard to find what one wants to do.
However, I also remember the situation before systemd. Every service had its one bash script to start/stop/status, maybe written initially from a template but each with its own bugs and idiosyncrasies. Many were hundred of lines long, and included several other files. Now, once a bug has been corrected in systemd, all the services benefit from it.
It also took 3 minutes to boot a desktop system. SSD do play a huge part in how fast boot has become, but the ability of systemd to transparently parallelize services startup also plays a significant role.
Sure, if a service is failing to start I need to find out why, instead of hacking a couple of "sleep" in the startup script and hoping for the best.