For one thing make is imperative and doesn't actually know what it's doing. Systemd is declarative. You'd need to replace all the options service files give you.
Make doesn't do dependencies between unrelated projects. A makefile can't say "I want to run if X runs, but I should run before them".
Make doesn't have supervision, you'd need some kind of declaratively configured poller.
Systemd is also parallel, there's probably some complexity there that make might or might not handle well.
I think the most important problems would only be obvious once you started using a replacement system though. Systemd almost totally replaces the need for any imperative code whatsoever for process autostart, configuration, and supervision, and that might be hard to do in a more modular setup.
You don't need extra stuff besides the service file. Everything is extremely consistent and done the same way for every service.
Everything statement that comment makes about make is incorrect, except the bit about polling.
Polling is better-addressed by having each service implement its own error handling. Restart loops are the wrong policy for most services. In the rare cases where they are actually the correct behavior, they’re trivial for the service author to implement.
Those that don’t understand make are doomed to reimplement it poorly.
How are restart loops the wrong policy? If it should be running, and it's not, how else would I fix it except by restarting it?
They're not exactly trivial. There's restart delay, number of times to restart, passing stdout through so the journal can get it, and there's failure reporting.
How is PID 1 supposed to know if my service failed when the restart daemon is still up and running, but my actual app keeps crashing? How can it tell the difference between my app and a supervisor, or a fully failed app or just one failed subprocess that my app can handle? Now you need some scheme for that.
If PID1 doesn't know what's failed, how would I get a list of all failed systems programmatically?
Systemd could provide a standard supervisor component, but then it couldn't ever do anything but restart failed apps, or you're back to people complaining about monoliths.
You'd have to have your service file explicitly call it with some command line args making your syntax uglier.
And more importantly, it might be harder for the systemd dev team because now they have a communication protocol between this restart daemon and everything else.
Or they could leave restart daemons up to the user... and everyone would probably choose 3 different ones, that might or might not keep up with compatibility. That would break the "One and only one obvious way" principle.
When you start splitting stuff up in tiny bits, you get more overhead, all the extra nice features seem to evaporate.
Make doesn't do dependencies between unrelated projects. A makefile can't say "I want to run if X runs, but I should run before them".
Make doesn't have supervision, you'd need some kind of declaratively configured poller.
Systemd is also parallel, there's probably some complexity there that make might or might not handle well.
I think the most important problems would only be obvious once you started using a replacement system though. Systemd almost totally replaces the need for any imperative code whatsoever for process autostart, configuration, and supervision, and that might be hard to do in a more modular setup.
You don't need extra stuff besides the service file. Everything is extremely consistent and done the same way for every service.