sh(1) doesn't change much either.
There are good reasons why you don't want to use shell scripting for this. See:
https://skarnet.org/software/execline/dieshdiedie.html
In the s6 suite of tools this issue was solved with
execline. If you have something legacy you don't want to re-write using shell scripts (or whatever else) you can simply pass it straight through using execline scripting. The way systemd "solved" the "hacky shell scripting" problem was using unit files which are even worse than shell scripts since it's hard to express complex logic since they aren't a real scripting language and instead are more akin to .ini files.
Lua and perl don't really matter but both are more general purpose languages that pull in their own stuff to make them work so now you have yet another thing in base that can go wrong. By comparison execline is smaller and more suited for this task. But given the choice between perl and lua the decision to use lua is probably the better choice. Other things I'm already using want lua so I personally need it anyway.
Perl is not bad despite its reputation and everyone deciding they suddenly hated it sometime around 1999-2000. There is a good reason why it exists and why people heavily used it over writing shell scripts. It's more portable and less prone to failing spectacularly. It's also good job security if you're the type of person into writing complex one-liners with it.
Perl and lua are certainly much better to have in the base system than something like python. Python is a glutton and it likes to break things every time a new version comes out. God help you if you want to use libraries.
A supervision suite
is not bad thing in fact it solves a lot of problems within a UNIX-like OS's user space. But it brings a lot of complexity of its own and there are hard problems you have to solve if you're going to commit to having it. For example, how will daemons communicate? Now you need a standard way to do IPC that
can not fail. You need to re-think how logging works especially if you're going to do complex starting/restarting of services at the same time. You have to make sure logs are ordered correctly and the logging mechanism is bullet proof so it won't ever crash and lose logs. You have to manage a complex web of dependencies. You now have to maintain and build some kind of database to ensure things start in the correct order and it quickly gets complex when you have things that require other things to already be running. You have to ensure the state is the same each time your complex tree of dependencies and daemons are started (one reason why using shell scripts is a bad idea). Most of these problems either require designing the service management with a lot of forethought or forcing new ways of doing things into the rest of the system.
Most popular supervision suites have been designed very badly hence why we're now in a situation where Linux boxes require rebooting when things in userspace are updated and the PID1 is now so large. Even the things that inspired systemd like launchd have a whole host of problems (e.g. use of XML). So people are right to be paranoid when they see such complexity being adopted by other OSs. The past has shown it's very hard to get this stuff right.
The faster boot times is a myth in my experience. At least in the Linux world. systemd is not only much harder to debug it's much slower at start up on every system I've used it on compared to things like runit, OpenRC, sysvinit and all of the others. As I said before "parrell start up" is mostly not real. Since you have to wait on daemons to "settle" anyway before they can actually communicate with each other and go on to do real work. Servers and laptops are rarely rebooted as much as people like to pretend anyway. A laptop is typically suspended to RAM/disk or the majority of the boot time is spent everywhere that isn't init/service manager firing up daemons at boot. Desktops and servers are typically running 24/7 and the few seconds at boot do not matter anyway. If your system is being rebooted all of the time you have other problems you should address. Similarly, auto restarting some daemon that's constantly crashing or otherwise acting up is not the proper way to address that problem. You should instead reconfigure/debug it or use something else. If it's that misbehaved then having some complex service manager restarting it multiple times an hour is just kicking the can down the road.
A lot of the supposed "benefits" provided by something like systemd is just
marketing and bad engineering.
