As for the eyeballs thing - historically the init RC scripts at the core of RHEL and such, the basic "SYS V" init clone, was not something that was written with extreme robustness in mind, it's not like they did a whiteboarded state machine design in there. And you'd not have been able to just send patches for it in most major distros. If there's no written out spec and real sw design on your init, you'll find people are afraid to change it.
Yet, the impact of fragility was quite low, as was the size of the single tasks. Run a script. Run the next one. Don't have any temporary files. Be stateless internally except for a run counter that makes things go either towards the desired "target" or down towards the opposite.
There was no interfaces except the init command, or telinit.
In a proper unix, a init 0 simpy ends init, leaving you in limbo. Linux (for convenience and to ease live for people who don't read a manual) had already gone far away from the simplistic design, and there seems to never have been the consideration (sorry) that the init clone should be kind of "MIL-SPEC" quality.
Now we're having the same thing, and again those concerns are not the upmost, but now it takes a vastly larger part in processing tasks, in how it interfaces with the kernel, in that it is accessible to non-root users and in that it processes input outside of when a startup task is done.
Those are mere differences. The problem is that again such aspects as hardening or failing safe / failing operative state seem not considered as core things. There are some measures to that direction (i.e. if resolved automatically respawns if it gets dropped out by malicious traffic) but not a lot.
Now lets assume the development process and responsiveness on concerns would change. That would be cool. (having worked with a few alternate inits I don't think it would happen, since none of the others have been hostile in any way)
Then we're left with one problem: The many-eyeballs thing is questionable.
In the normal init system, due to the lack of interfaces, the "attack vector" is getting an init script in place, which only root can do.
Then it's allowed to do whatever it deems necessary, and you're at the mercy of the author as far as i.e. dropping privs goes. If he knows how to use su, it'll be su, if he doesn't then it'll be sudo, and so on.
But the only way he'll attack your init system is if he puts something in there that overwrites the binary/script. He'll not even easily "persist" inside it, since any variable he'd export would be squashed when the next script is run.
The language (sh, ideally, POSIX only) is to the point where you got a sec hole for every 10 years, and normally none at all.
And, I wanna stress that a bit - there's just too little to attack and no way he can get an attack it after the system is up.
Those differences are there. They can be cause for worry or not. But the "shared code base" argument is mostly moot.
The argument that you get rid of bad priv-drop wrappers has two discussion points. one, that those are either bad design (local nat is a thing) or necessities (ssh) and two, that in the sw world we've learned that for any security related issue we need to prioritize it among our worst issues, and rather overdo solving it than not.
This is not happening.
Right now few people are looking for exploits, but it's not like this is an interesting topic for sec researchers. Once that happens and meets with a billions-of-installed devices-not-getting-patched base, I'm a bit worried.
We might have benefits in the tech world. For the people who benefit from whatever our systems do, there's benefits insofar as automatically restarting services is becoming more common (because apparently it was just too hard to read up on daemontools for non-HA setups), but I don't wanna be around and need to justify if we repeat some shit like CodeRed right in our init.
Show me how to shut down that now as opposed to the footprint of a single(!) shell script being run on boot. The countermeasure has gotten a tad more complicated. And as for daemon-reexec I'm still wondering why a
zypper ps -s would still see old systemd parts in memory afterwards.
I've skipped comparing to SMF - which one of the systemd devs called "Solaris" or some parallels to AIX, like binary logging and SRC.
SMF had a very open, inclusive, thoughtful and documented design process and I think that's the big differences lie. No idea how that will ever be mended.