To pick on cron, just from my own experience:

"I wonder where this scheduled task is configured" -> "Lemme check /etc/crontab" -> "nope, I guess maybe /etc/cron.d?" -> "Nope, lemme check /etc/cron.hourly/daily/weekly" -> "hmm, not there... maybe I want `crontab -l`... or it's running as a user, lemme check that list and run through `crontab -l -u $USER"

Finding out that I didn't notice a cronjob was failing because the stock methodology for notifications is email, and relies on the system having SMTP configured and having MAILTO set in cron.

Realizing a cronjob wasn't running because some, but not all, of the cron options have character limitations like "the file name can't contain any dots".

The total lack of dependency management, so anything I wanted to run @reboot needed to handle its own dependency checks and sleeps to make sure I didn't say, try to run puppet before the network was up.

On the networking side, I started using Arch when the config flow was "edit bash arrays in /etc/rc.local". I've used netcfg, netctl, and now systemd-networkd. systemd-networkd is easier to reason about, easier to debug, more powerful, and more portable between systems.

My question though: how did we manage to run infrastructure using cron for decades and did not feel any of that pain?

My take on the answer is this. Failures: we have /var/log/something for this and typically it's obvious something is not being executed. Many files: yes, there are different configs but don't you remember where you typically put your cronjobs? For example I always use user's crontab, so this is where I would look for the job spec.

Dependency check is one of the main reasons for systemd as PID1 if not the main, so hands down, that's valid and true.

But also what we consider to be painful has evolved. When all systems were to some extent a hand-gardened entity, maintained by some specific system administrator, it was easier for them to have a personal standard. It didn't matter if I used cron.d and you used crontab, as long as on our own systems we kept one method. Increasingly, servers are more ephemeral, more horizontally scaled, and more automated, and systemd timers are just easier to work with in that model.

In a decade or so, I'm sure we'll have further modified how we handle systems, and something else will come along that solves painful things about systemd.