I used upstart deeply around 2012-2014 in a commercial product based on Ubuntu. I remember two problems with it which had me waiting for Ubuntu to switch to systemd (unfortunately my employer ran out of money right when that happened). The first was that Upstart's model is upside-down: where systemd has units that depend on units, Upstart has jobs that are activated as other jobs complete. Whereas you would tell systemd that (say) Apache depends on syslog and ask it to try to start Apache, and therefore systemd would first try to start syslog, you tell Upstart that Apache can be started when syslog starts, and that you should start syslog, and then Apache's dependencies are met and Apache can start too. Instead of having a single target (like sysvinit runlevels or systemd's multi-user.target) that it works towards, Upstart just starts ... stuff ... untill it's done. Upstart did have a runlevel concept, but as I recall it was an event that triggered jobs to start, not a target. See http://upstart.ubuntu.com/cookbook/#critique-of-dependency-b... for Upstart's defense of this approach.
(systemd is hardly unique in being dependency-based instead of event-based - but it is a strike against Upstart in particular. Also, while one of the stronger claims of why Upstart should work this way is it matches the evented mindset of udev, systemd can handle events from udev just fine, by just having it add additional targets - and in the end, systemd consumed udev.)
The other was that it was hard to deal with its bugs. I had a job that wasn't activating. I spent days chasing it, including attaching a debugger to Upstart, and eventually gave up. I've used systemd extensively and have not had "Why isn't this service starting" bugs. (I've certainly had that confusion, but I've always been able to figure it out quickly.) systemd has in my experience been reliable and trustworthy. I'm not going to say that it's bug-free, or that I like its implementation, or that I have no complaints about it. I am going to say I haven't been frustrated by it - even when running very old distro versions with lots of known bug fixes upstream. That's very important for whether I'm happy with it or whether I'm going to switch back to sysvinit and find something else for service monitoring.
(systemd is hardly unique in being dependency-based instead of event-based - but it is a strike against Upstart in particular. Also, while one of the stronger claims of why Upstart should work this way is it matches the evented mindset of udev, systemd can handle events from udev just fine, by just having it add additional targets - and in the end, systemd consumed udev.)
The other was that it was hard to deal with its bugs. I had a job that wasn't activating. I spent days chasing it, including attaching a debugger to Upstart, and eventually gave up. I've used systemd extensively and have not had "Why isn't this service starting" bugs. (I've certainly had that confusion, but I've always been able to figure it out quickly.) systemd has in my experience been reliable and trustworthy. I'm not going to say that it's bug-free, or that I like its implementation, or that I have no complaints about it. I am going to say I haven't been frustrated by it - even when running very old distro versions with lots of known bug fixes upstream. That's very important for whether I'm happy with it or whether I'm going to switch back to sysvinit and find something else for service monitoring.