Maybe because you've never had the ability to use such timing requirements. Having more advanced tools available also makes you think more in them. If you only ever used cron, there has been no reason to think about a service running every hour or immediately if it missed the schedule. Because the only tools are every hour and on reboot. And no option to make "every hour" mean "between script invocations" instead of "on the hour of the schedule".

All of those systemd features have been implemented hundreds of times as buggy hacky shell scripts launched by cron.

This was my experience. Cron was great because it did what I needed it to do and I knew how to use it. But over the years I accumulated all sorts of hacks to avoid pitfalls. When I learned systemd timers I didn't like the complexity, but as new needs arose I thought about both cron and systemd and realized that systmd timers were better for 75% of my needs.

There are lots of things that I have the ability to do that I've never had the requirement to do. I call those things "bloat" because they are unnecessary features that add complexity and bugs to the system.

Unnecessary to you maybe but not to other people. It's a tiny bit rude to simply call a feature rude just because you don't use it. After all, by that argument I could call the screen reader software or the Speech-to-Text bloat. But they aren't.

I had hard requirements for randomizing cronjobs plenty of times. Once you have a large number of systems it's the default rather than the exception.

In FreeBSD see the "-J" and "-j" options to cron.

Does that add a static random delay on bootup or does it randomly delay the job each time? Because for timers you can pick that for every single timer individually.

agreed, and more importantly it's possible to implement these scenarios with cron if they're needed. i'll take a simple building block over bloat. where does the bloat stop? i can come up with tens more scenarios that timers doesn't cover.