This is just motte-and-bailey. You're shifting the definition of the "unix philosophy" between the general idea of interoperability, and the UNIX design of small programs that communicate via text and are glued together with the shell and pipes. The argument doesn't work if you actually use a consistent definition: the former is an obviously good thing but also an area where systemd scores well, and the latter isn't necessarily a good idea when you're doing something other than ad-hoc text manipulation.

I honestly don't understand why people want to do all these rhetorical backflips in order to maintain some kind of bizarre religious reverence for the "unix philosophy". UNIX's design was quite mediocre, it only looks brilliant when compared to the DOS lineage.

How about you make an actual technical criticism of systemd instead of hiding behind vague generalities? In particular, why is it bad that all the functionality needed to manage and monitor daemons is in one program? How would you split it into several programs in a way that maintains systemd's robustness for administrators and convenience for developers? What would be the practical benefits of this split to the users and developers (no "philosophies" please)? Can you justify that this proposed split would reduce systemic complexity (the complexity of the whole system) instead of actually increasing it by just shifting responsibilities onto daemon developers?