I think the point is you can't replace each of those binaries with alternatives. The monolithic nature of systemd is not just a function of the raw number of binaries involved.
Something being (theoretically) possible doesn't mean it's practical.
The attitude of the systemd (And Freedesktop.org folks in general - and please don't give us the usual Lennart cry of "No really, we're NOT the freedesktop.org people!" - despite all of these projects sharing a tightly knit community of people steering them) devs and their treatment of their projects has meant for some you basically do things their way or the highway.[1]
It's already a pain in the ass to strip udev out to keep using it if you've decided to not use systemd. And that's just taking one portion of the system that was promised to be kept easily independent of the rest of the muck, not trying to make other services work within the framework of a systemd system.
As it becomes the standard across all of the major distros, I find it hard to believe that it will become easier to separate systemd parts from one another than it is now, because there becomes even less incentive to do so.
I don't have much of a horse in this race, because I've long since migrated the vast majority of my production systems to FreeBSD and OmniOS, and out of the few that I have that are running linux still, some of them are using systemd. I don't particularly like it, but instead of complaining about it and doing nothing, I've minimized the impact I feel from it.
Those are the external APIs that the various parts of systemd expose to non-systemd applications, the internal APIs are not documented and are subject to change. Basically, you can't just replace part of systemd, you need to write replacements for the whole thing that reimplement all the same APIs in ways that are compatible with it because stuff like Gnome now relies on them.
That's part of the reason why Ubuntu gave up and switched to systemd - a lot of the desktop stuff they shipped relies on logind etc upstream, and it just wouldn't be practical for them to implement their own versions of everything that got Borged by systemd. (Edit: in fact, that page lists logind as something that cannot be independently reimplemented or used separately from systemd.)
True, but I think you could say the same thing about git. It's a big bundle of binaries, and there aren't alternatives available that you can swap in and out. And yet, git is seen as the perfect example of the Unix philosophy.
People whip out the Unix philosophy the same way they do every other philosophy: whenever it supports what they already want. I don't think it's a valid argument anymore.
I think that's moving the goal posts a bit. Git is a VCS. You can replace some of git with RCS. More of it with CVS, or all of it with mercurial (modulus a few git corner cases). Git interfaces with email and diff/patch. It can produce text output that can be turned into reports with awk if you're so inclined.
I think arguing that systemd breaks with the unix philosophy is entirely valid -- it's taking what could (does!) arguably exist as separate systems with clean, separating interfaces into one monolithic whole for a somewhat unclear gain.
I wonder how hard it would be to write a compiler/translator from systemd service files to sysv init-scripts?
