All those init.d scripts do about 95% the same thing, all hacked together in shell. Most of them are probably just slightly edited versions of some few paleo-scripts.
Set the location of the pid file, set the path of the executable, set the command line flags/options, maybe change some flags/options based on some options in another file like /etc/sysconfig/daemon_name (also shell commands which are just executed inline), then the start/stop/reload/restart/status case statements. And the dependencies of course.
It really could just be config files like xinetd or logrotate except for a few hard cases where you could have a "run this script" attribute.
Replacing "run these scripts in the right order" with a config-driven "service manager" sounds like a sensible development. (Not necessarily the One True Way, but certainly an option). Pulling complicated things like chroot, capabilities etc into one place, getting them right, and then letting services specify what they want, rather than everyone having to re-invent the same shell scripts sounds like it would encourage use of those features. I can even see some more advanced functionality to specify checks / frequencies for "is this service still running / alive" that effectively moves a lot of watchdog functionality into the "service manager". I'm somewhat confused (without reading the implementation details, just conceptually) as to why the "service manager" is also providing DHCP client, SNTP client, virtual consoles, session management... I can completely understand why the "do one thing" crowd are taking objection to that. Regards, Tim.