The same reason why most people stopped manually editing some random files via FTP to do deployments: to get a proper reproducible, automated and monitored production environment.
I think there's a threshold below which this is just unnecessary infrastructure overhead, and I'd posit that most cron use cases fall below this threshold. If yours is above it, well and good.
Cloud setups are not reproducible, because you cannot reproduce the same env locally or in the other cloud.
Does crontab on a self-managed VM guarantee at least once delivery? For many, if not most, use-cases that guarantee is critical.
No. But I don't think there's any environment out there that is going to 100% guarantee that your cron succeeds. Even if it is reenqueued on failure, it could just keep hitting the same problem and crashlooping. You still need some kind of failure reporting, and a human to jump in to fix whatever went wrong.
Because managing servers adds a lot of tech overhead (OS and security updates/access control/disk/HA/monitoring) + provisioning/config + deployment.
That said, there will be a time when your SaaS costs more than managing infra.
crontab is just the schedule, there's a bunch of job handling missing. systemd timers get a bit closer and are worth learning for those that still touch actual Linux machines.