I hate to say it, but this is just a rant by a RedHat/CentOS admin who has started using Debian/Ubuntu for the first time and just doesn't know why things are done differently there.
Why are there so many non-standard ways that a package can decide to not start? I really appreciate that the package maintainer is trying to do the right thing, but it's ridiculous that there isn't a way to do it - there's the Debian default and then there's whatever the packager thought up.
That's nuts, and needing to manage the same resource twice in puppet isn't a tragedy or big deal, but it's a symptom that something is wrong.
In your blog post you only mention one way of controlling startup- via an environment variable sourced from a file in /etc/defaults. This is the standardized, documented place in Debian for controlling the behavior of init scripts. Offhand, I can't think of any other ways I've seen packager maintainers controlling startup. I'd really need to see more evidence before agreeing that things are "ridiculous", "nuts", or "wrong".
http://www.debian.org/doc/manuals/maint-guide/dother.en.html...
More examples here: http://serverfault.com/questions/526075/fixing-services-that...
As it is, figuring out exactly how to do this has to be done for each service. It's tedious, IMO, though I understand the history of why this is the case.
I disagree that this is currently really more of a problem on Debian/Ubuntu that it is on Red Hat. E.G. If I want to manage BIND via puppet on Red Hat, I'm going to have to care about /etc/sysconfig/named.