Containers have nothing to do with an inability to multitask. They're about, well, containing changes. That is, if I update glibc I don't have to worry about testing 47 different services on the host to ensure they all work before walking away. Instead I only have to test one, since that glibc is private to a single service. They do consume more RAM, of course, since less is shared in memory. That is the tradeoff.
As I said, they are just unnecessary bloat. The problem you are trying to solve is self-serving and endless. let's say you need to update glibc, then you add containers, now you need to update your container software so you add container-containers, then next you need to update your container-container software, so you need container-container-containers. No matter how long you keep up, you're still going to end up with the same problem and additional ones. But by now, the system has devolved into a slow mess that no one wants to touch. So you go and buy a new server and hope things are different this time.
The whole point of a robust design is that it makes errors harder to commit, and handles them better. If nobody wrote bad code we wouldn't need process memory isolation either.
Memory protection is a basic requirement for security in a multi-user environment.
That is the problem - the files are editable. That means that every time you update a package you have to re-merge the stock scripts with all your changes. With a systemd drop-in you can override a configuration setting without editing any file owned by a package.
Assuming there even is such a config setting in systemd, and that it works.
You can run scripts from a systemd unit if you need to, but the point is that 95% of the time you don't have to.
Problem is, for the most part people want to get rid of behaviour in systemd, which doesn't work for them or is otherwise useless. And in many cases it simply isn't possible.
You're basically arguing about the merits of procedural programming over declarative programming
Not really, both would work, but fewer people are good at declarative which means it's bad for system tools. I'm arguing flexible design over monolithic when it comes to something like init.
You never want to reboot for minor system changes, so init needs to be as flexible as possible, to accomodate any kind of change. Systemd, the monolithic binary that links all the way up to GUI layers. You'll need to reboot for just about every software update.
It really is the worst solution anyone could ever come up with for a problem that never existed in the first place. I'm not sure I could come up with something more stupid.