This is not true. That is an aesthetic discussion. People dislike systemd because it is insanely bad software.
>I'd argue that almost everything systemd brings to the table in a default setup are all things you'd need anyway, minimalist or otherwise.
That is legitimately insane. No, you don't need the things systemd brings to the table. Systemd replicates multiple parts of what your systemd already does. E.g. it replicates the fstab by providing mount units. No normal user needs those, fstab works just fine, yet for some reason they include it anyway. Systems now can also boot your system, again it is repeatedly implementing already existing functionality. Same for DNS, surely you absolutely need an init systemd to handle DNS...
That is why people dislike it and why it is obviously not "minimalist" in any way, replicating already existing functionality is the exact opposite of
>They're just all handled by one overarching service, which I think is the real argument against systemd.
No. The argument is that systemd is really bad software which repeatedly reinvents already existing OS features in its own way, even if those features are near unrelated to an init system.
I don't care about "Unix philosophy", no system should be designed like systemd. People complain because it is badly not because it violates some barely defined rules about what "Unix should be".
I criticize systemd because for months my full time job was dealing with it. I suspect the minority of systemd haters are actually people like me, who actually had to do non-trivial things with it and realized how bad it is, if you actually have to do things with it.
Hating systemd is sort of a joke in certain Linux circles, where "Unix philosophy" and "minimalism" are tossed around. I don't really care about that discussion. Systemd is awful by any philosophy which aims to provide good software, for almost anything you can fill the word "good" with.
All of them are worse than what they are replacing - more limited and more buggy. Sometimes because they are just new, sometimes because the authors don't know what they are doing. In any case, why switch?
Regarding "part of", there's a nice motte and bailey argument from systemd that they are absolutely not parts of it when talking to critics, but when it comes to shipping and using them, they are.
It was especially bad when udev "moved in with" systemd, there were promises to keep it working without systemd. These were swiftly broken. Assuming good faith from that crowd is a mistake.
Fortunately, there is a fork of udev that works without systemd, and you know what, it's not even a difficult one. So what were the strong technical reasons for adding the dependency?