Same couldn't be said about supervisor, the solution you already had running (well, maybe strike init)?
And it's not installed by default because it doesn't solve the problem of a service dependancy graph.
I doubt that supervisor is not installed because of not solving something it evidently does not want to solve, but that argument at least looks valid to me. Just in case you are not aware, https://github.com/Supervisor/supervisor/issues/122 lists two solutions (wait_for_it.sh and a supervisor plugin that adds dependency resolution).
The more systems something sits under the more places there are for it to cause a problem because it doesn't work quite how the upper components expect. At a bare minimum, you'll often run into problems with the included package management system (and how it may reload systems for security purposes after patching) if you don't take care.
nano sits on top of everything, and the few things that might rely on it use a very standard and not very extensible interface (the EDITOR environment var). It's not really equivalent at all.
Not sure what your point is (well ok, I am, and I agree), but you just lost
Rewatch the first half of the video and imagine it was a bunch of random tools with proper names (like grep, ntpd, syslogd) etc, that had all been built separately but happen to nicely tie into each other, rather than "systemd-blah"
Since systemd, I just do a service file.
So despite all its shortcommings, I now have a standard, well documented, init system that I can use accross all the distros I use, which happens to provide all the features I need.
I'm sure all the power user complaints about systemd are legitimate, but I really don't care about those. I just want an easy way to setup custom deamon on ubuntu and centos.
Provide a better system, that solve those problems, and I'll use it. I really don't care as long as my problem is solved.