This is a great write up and was really interesting to read.
My question is why would the proposed changes are not already included upstream?
Isn't a faster boot what everybody wants?
Yes, but glancing quickly at the article some solutions are not generally acceptable, such as moving filesystem processes to the application code. If you have a RPi project where you plan to run a single Qt app then you can do stuff like this, but that is generally speaking not the use case.
Because these changes remove networking, USB support, sound, debugging support, and even the entire init system. It's useful if you need to boot into a single, simple app without networking or USB as fast as possible, but it's not useful for general purpose computing.
I’d rather my computer booted and then signalled when everything I want was ready, rather than hide the init time after claiming to be ready.
I’ll rather have slow boot and proper UEFI support so I can boot any vanilla ARM64 Linux distro (Debian proper), instead of images/distros which have been crafted to be device-specific (Raspbian).
I boot this thing once every second month at most. I honestly couldn’t care less about boot-times.
Luckily for me, there are solutions to my problem too ;)
Incidentally, I have used this for for the ESXi Fling for the Pi when benchmarking it against KVM performance (for those curious, KVM far outperformed ESXi), but I heard that it doesn't work as well for Linux distros (some hardware was broken last I heard [a few months ago]).
But yeah, I agree that getting UEFI support and standardising the ARM boot procedure is very useful for all of us.