I think this Debian fork talk is a bunch of nonsense, but so is your comment. It's the classic "systemd or sysvinit" false dichotomy, as evidently a ton of Linux users have never stepped out of their cage to ever look at anything else.
Besides all the sysvinit alternatives (like depinit) that have popped up throughout the years, fixed most of its deficiencies and were promptly ignored, even having a shell-based boot doesn't mean you need to resort to the antipatterns that Linux distros have been doing - look at what the BSDs do with /etc/rc.subr and rcorder(8). Though, to some extent, this can be blamed on sysvinit's flawed abstractions.
If anything, making a "systemd or sysvinit" dichotomy only tells me you're unknowledgeable.
You're totally right about the false dichotomy, but I don't see why you think other init system were ignored.
Debian used a really open process to decide the new default init system where every developer could propose any init system provided that someone offered to maintain it.
Since SysVinit, systemd and Upstart where the only ones with a credible maintainership (OpenRC didn't work on Debian until a few week after the discussion started) the discussion was centered on those three.
So it's not like other init system were ignored, it's just that noone bothered to do the actual work to make them suitable replacements.
My hypothesis is that systemd was the first to provide enough benefits to motivate people to implement the switch in Debian.
From a distribution maintainer the fact that systemd tackles many loosely related problems is an actual benefit, since now said maintainer just need to coordinate with an upstream project instead of having to maintain dozens of special snowflake systems (eg. to set the hostname). This is what most systemd critics fail to accept.
Oh, and the shell is nice but it's one of the worst languages to implement anything non-trivial, http://www.dwheeler.com/essays/filenames-in-shell.html is enough for me welcome the idea of getting rid of it in the boot process. :)
Besides all the sysvinit alternatives (like depinit) that have popped up throughout the years, fixed most of its deficiencies and were promptly ignored, even having a shell-based boot doesn't mean you need to resort to the antipatterns that Linux distros have been doing - look at what the BSDs do with /etc/rc.subr and rcorder(8). Though, to some extent, this can be blamed on sysvinit's flawed abstractions.
If anything, making a "systemd or sysvinit" dichotomy only tells me you're unknowledgeable.