I'm in the same boat - I wind up in a situation where I find myself missing the features, stability, coherance, and integration of systemd at least once a week in my day job, where we currently use Ubuntu with upstart.
For me, it's a combination of things:
1. Proper dependency management, where I specify dependencies as they are, rather than flattening the dependency graph.
2. Proper service supervision. I've had upstart lose track of running processes, which is silly - you had one job!
3. Ability to decouple the init system's view of "process is running" from "process is ready/live". This is nice if you want to await liveness by letting the system supervisor tell you if the service is live or not, rather than writing a bunch of external scripts or checks.
4. A single place to modify the way system services are run, and unified config for e.g. resource limits, and tools for working with them.
5. Simple exploration and interleaving of logs from various communicating services via journalctl, which is insanely helpful for debugging things in a distributed system. You can see the calls come in from the network and bounce between services, and see exactly where something goes wrong. You could do this with other solutions, but I get this out of the box with journalctl, and I can look in more detail at any of the services, or when I'm checking a service's status.
It's true that many of these things could perhaps have been done in other ways, but the fact is that the systemd developers did the work to make it happen and now I can focus on my product, rather than on learning a bazillion pieces of plumbing to enable me to ship product. I'm fine adapting a few things to run via unit files instead of shell scripts if it means I can ship more correct and more reliable product in less time.
systemd is less stable than upstart (and sysvinit, obviusly), "it lacks maturity" says the author. You've had several problems with upstart, but count yourself lucky, certain problems with systemd will take down the whole system, and make it unbootable too!
systemd is not reliable, unlike eg daemontools, the developers are busy adding new features and don't care at all about old bugs. They say if you're not using one of the latest kernels, tough luck. So you're continuously debugging systemd "modern innovations" instead of focusing on your product.
If you're using Ubuntu, let's hope that by the time it gets adopted, systemd has evolved into a functional, dependable component. I wouldn't bet my product on that, though..
I've been also using systemd since Arch switched over, I've discovered bugs and vulnerabilities. But the thing is, if you're happy with systemd and works well for you, great! I've seen this very prevalent attitude in systemd users, the less they know, more fervently defend systemd, even if they think it sucks, they tell you it's the best thing ever because they're using it, and they always have to use the best.
Arch is bleeding edge, if you've never seen a bug, you haven't been paying attention. So, again, you've never suffered a problem with systemd. Now do a web search, and in less time it takes to write "[citation needed]", you'll see that this is real. Sorry, but systemd has bugs, just like every other program, but by being so intermingled with the kernel, the consequences are much worse.
If you know of some old neglected bugs like you keep saying then point some out. I would love to see an actual source on something other than the constant made up retorts of "PID 1 now has an HTTP server" or "Now kernel panics display a QR code".
I definitely don't want to hide problems with my init systems behind a supervisor that has its own host of problems. The union of those two products does not make a more stable, easy-to-reason-about system.
Granted I could choose something better than monit, but then why add another layer to hide brokenness, when we have the capability of doing it correctly in the first place.
Being able to see what started what, cgroups, which binary produced what output, automatic process restarting is what I like for using on a server. I also like the nice timers output and that I don't need an additional cron or network configuration utility.
