Upstart has a little problem: it erases the difference between something having a startup script and whether that script is activated or not. There is no equivalent in Upstart to the distinction between /etc/init.d and /etc/rc?.d; everyone puts startup configurations directly in /etc/init, where Upstart will process them. This matters quite a lot to me, because there are plenty of packages that we want installed without having their daemons be active.

Editing the /etc/init file is not a solution (even if it's done by a script), because the file is owned by the package, not the sysadmin. An Upstart .conf file contains a great deal more than whether or not a daemon is enabled (and under what circumstances); it also has how to start the daemon and what associated processing you need to do. This means that its contents are logically tied to the rest of the package and may need to be updated when the rest of the package is.

If you edit the file and the package is updated, either your changes are lost (and the daemon either starts running when you didn't want it to or stops running when you did) or you now get to merge your changes with the package's changes by hand. Neither is a good outcome when all you wanted to do was stop the MySQL daemon from running by default.

There's also a consequence for how people package daemons. It used to be that a lot of daemons were shipped in a default-disabled state, where after installation they were just available but you had to use chkconfig or the equivalent to turn them on. This was perfectly viable when we had a chkconfig (and GUI versions of it), but Upstart removes all that and makes it much more difficult and annoying to change the enabled/disabled state of a daemon. I suspect that the result will be a lot more daemons being installed default-enabled (if the packager has to pick an option, it's the more useful one), and in turn this means I'll be installing a lot less daemons.