Except that the author does not end the discussion at “it doesn’t follow the Unix philosophy.” Granted, they do spend a number of words refuting the argument that systemd is modular; whether or not it’s a strawman, it sounds like you already agree with the author on that point. While they do pay some lip service to the value of the Unix Philosophy, their arguement hardly ends there.

From the article, (bold emphasis mine):

This lack of modularity – where “modularity” means free choice in interchanging components for other, unrelated projects – is where most of the criticism of systemd stems. It’s the purest, and most important, criticism of systemd, but my personal grievances against systemd go further. Because, in my experience, systemd isn’t good software.

The author provides evidence for that claim with examples regarding journald, networkd, and session keyrings. None of those criticisms are specific to the Unix Philosophy. Their whole point appears to be “yes, I value software that follows the Unix Philosophy, and systemd does not, but I believe there are many other valid reasons that systemd isn’t good.”

Of course these concerns play into each other, but the nuance there is kinda the whole point. The author points out that it would be a lot easier to use only the good parts if systemd had a more genuinely modular architecture, but it’s simply not built for that. And it’s a real and material example of a negative consequence of not following the Unix Philosophy. Rather than say “it’s not developed with the UP in mind, it must therefore be bad,” the author gives a tangible example representative of why they believe that to be important.

Just as the Unix Philosophy is a thought-terminating cliché (because of course it is), it is similarly unhelpful to claim that consolidation brings performance and cross-cutting capabilities. The proof is in the pudding, and as critical readers we should not overlook valuable perspectives like the one the author has brought.

(Not that it’s critical to your point, but we’re you trying to argue that Wayland is monolithic? I have to assume you didn’t mean it like that, since it’s a protocol that decouples clients and compositors, and it’s certainly not monolithic in that sense)

handwaving away the same argument against Linux or Wayland

Honestly, I would be happy if there was a mature implementation that was practical to use and was more modular for these too. I’d argue Wayland is much better than X11 in this respect, since the Wayland protocol is much more minimalistic in its design, so I think a big reason why X was superseded was the need for removing things that had been needlessly integrated in the X server and added technical debt.

If there had been usable and working alternatives that were less monolithic at the time those were launched, and people were actually using them but had to switch due to the pressure of other bigger projects… then I’m sure there would have been criticisms too.

Imagine if someone came and proposed “graphicd”, a service that combines not just compositor & display manager but also management of priviledges (like polkit), GUI toolkit (like a Gtk/Qt replacement), password manager, terminal emulator, filebrowser, web-browser and any program that might benefit from tight integration with the GUI environment. And it used protocols and methods that are entirely incompatible with Gnome, KDE or other more modular desktop environments, but the API/ABI is so big and fast moving that it’s very hard for alternative apps to integrate well with the core of graphicd (the external API on the components is stable, but not the API between the components and the core). Then it started becoming the default everywhere, with some programs adding its specific components (and along with them, the graphicd core) as a dependency.

Filesystem mounting can depend on network availability for example

This is one of my pet peeves with systemd… I’ve multiple times tried to use mount units (the “systemd-native” way) but I often have always ended up just relying on either the older /etc/fstab configuration conventions or layers like gvfs and custom scripts (through the init.d-like rc.local compatibility service…) because when writting systemd units to mount conditionally remote drives that might or might not be available they sometimes (not even reproducibly) led to problems in one way or another (like sometimes slowing down my boot or even my shutdown).

The issue is that systemd is considerably more opaque and complex… so it’s hard to tell whether something is a bug in the software, an intentional behavior / quirk, something specific to particular circumstances/cases or an issue in your configuration.

And I’m not saying all of what systemd did is bad, it has advantages… but acting as if it doesn’t have problems that could be smoothed out with a different approach would not be right either… it’s not like it’s impossible to do what you are stating in a modular way, for a long time before systemd was a thing we had syslog implementations (like rsyslog) that handled structured, secure remote logging across networks without needing a monolithic init system to dictate how logging architecture should work.