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"
Same couldn't be said about supervisor, the solution you already had running (well, maybe strike init)?