Well, "monolithic" isn't very clearly defined, either way. There's multiple interpretations, but systemd does fall under tight coupling. Its modularity is somewhat arbitrary. A lot of auxiliary daemons can be configured out of the build, but some others like generators and most damningly journald, cannot.

Yes, you can run regular syslogd and crond implementations beside systemd's journald and timer units. To be honest, it would be pretty ridiculous if you couldn't, and it's not much of a consolation.

Although journald can be effectively disabled by forwarding to syslog (however, PID1 itself no longer supports syslog as a target), the systemd developers do want it to be the primary syslog mechanism on a Linux system, and are pushing it as such. Yet due to choosing to use a binary format similar to a RDBMS, but without the transaction consistency of an actual RDBMS, it's prone to unnecessary corruption. This was deemed not to be an issue, apparently: https://bugs.freedesktop.org/show_bug.cgi?id=64116

Then you have an (optionally network-enabled) system logging service that stays resident without being used, a potential attack vector and really just a huge, completely unnecessary sink to proxy your actual syslogd of choice to.