WiFi absolutely should be a separate component; the unix philosophy is an excellent defense against servers in a datacenter trying to install a WiFi stack.
1993's sendmail is more complex than qmail. The latter uses a modular system, where each subtool does its job well, rather than sendmail's monolith design.
Linux was(is?) the system. Shell scripts could configure the system, reasonably well. Systemd meant it was no longer possible to simply fix a linux distro that had it...a massive recompile and intricate understanding of many low level systems was needed.
No, you shouldn't need to know about PDP-11s to fix your buggy wifi, neither should you need to know a massive binary subsystem to configure your wifi either...
So as far as doing its "one job", it did/does it fairly poorly, even today. It is a lot more standard and it does get points from me in that respect, but it fails at being a configurable system completely.
What kinds of problems are you hitting where you need to recompile systemd?
Configuring the system with textfiles only works if the system anticipated all your needs, and to anticipate all needs is not only complex but error prone.
There have been times where I needed to do something that wasn’t available in the unit file syntax, so I just do it in a shell script and ExecStart that.
If so, perhaps it is less of a problem than it used to be.
It still doesn't fit every need but it's better if it can get out of the way when told to.
It seems to be made for, and works well for, a modern ephemeral infrastructure workflow.
Build stuff to work with an unmodified distro, wipe it and reinstall if it goes wrong.
I counted no less then 64 related executables related to systemd on my system.
Accusing systemd of "not doing one thing and doing it well" is like accusing the GNU project of not following the Unix philosophy.
It is currently the only linux resolver stub, that supports link specific upstream resolvers. In the terms that user would understand, your split-horizon DNS works correctly over your VPN.
The Unix philosophy is about function, not form. Say you have a tool to send
something over a network. In 1993, that tool can get by being quite simple.
In 2024, that same tool now needs to be more complex, just to do the same
'one job' and to 'do it well'.
Systemd, particularly journald, violates this severely by snarfing any stream you want to send to /var/log or wherever and locking it in a binary database somewhere, that you have to use journalctl to access.
I have no problem with journald as an idea, but the audacity that it knows better than the user what to do with stdout/stderr is insane, and 100% anti-Unix.
The Unix philosophy is about function, not form. Say you have a tool to send something over a network. In 1993, that tool can get by being quite simple. In 2024, that same tool now needs to be more complex, just to do the same 'one job' and to 'do it well'.
It's a consistent insistence that the 'single job' be defined today just as it was in 1980 that results in Linux requiring hundreds of packages to be even remotely usable. Oh, you want Wi-Fi? Well, that's not really the job of the networking stack, the job of the networking stack is to connect PDP-11s together...