This is precisely why it is valid to say that systemd doesn't align with the Unix philosophy, and yet it's also valid that many people such as yourself like it.

I don't want my init system to replace cron. I don't want it to manage logging. I don't want it to have any debugging capabilities. All of these things can be done with other programs, arguably in a much more flexible and robust way.

An init system should do one thing (well): manage system services. Within that context, it should start services on boot, keep them running in the background, and allow the user to create, stop, and start services. That's it. And it could be argued that even those responsibilities are too broad for a single program.

So I understand that you and many others like that systemd provides solutions to all of these tasks in an integrated way. But you should also understand that this does in fact go against the Unix philosophy, of small, independent, but composable programs with a single responsibility. It "proposes" alternatives to many other tools for no particular reason, until users are effectively using GNU/systemd/Linux.

And, yes, I know that technically systemd is not a monolith and is composed of many programs, but that is a moot point. It is a single project, maintained by a strongly opinionated team, and given the importance of it, most distros go all-in, so users are strongly recommended, if not forced, to use all of its programs. In many cases it's not even possible to use one individual systemd program idependently from another. This is why systemd is seen as a kraken that takes over the entire system if you do decide to use one part of it.