I generally agree with the weak points that the OP pointed out regarding cron. That being said, throwing out cron, or any other built-in system tool, isn't always a great idea.
When you adopt a new scheduler, you're inevitably creating work for your enterprise. It's yet another thing that must be learned and documented. There may be a new syntax to learn, which will mean you're incurring training costs (and the cost of errors) down the line.
Programmers love to improve things, but there's a real world cost to change that can't be ignored. cron may be archaic and lacking power, but it's well understood.
As for enterprise schedulers, they've been around for years. Off the top of my head, I've worked with 'Autosys', and 'Appworx'. These were robust, enterprise-ready schedulers that supported conditional execution, locks, as well as their own scripting language.
To be fair he didn't say throw out cron. He said cron will have a place for rotating log files etc. Which to me is infrastructure type stuff and not application level.
So the sysadmins will still use cron to do the infrastructure type jobs. But when a programmer needs something in his app to be scheduled he can use the replacement, this also frees them up from asking the sysadmin to install a cron script.
When you adopt a new scheduler, you're inevitably creating work for your enterprise. It's yet another thing that must be learned and documented. There may be a new syntax to learn, which will mean you're incurring training costs (and the cost of errors) down the line.
Programmers love to improve things, but there's a real world cost to change that can't be ignored. cron may be archaic and lacking power, but it's well understood.
As for enterprise schedulers, they've been around for years. Off the top of my head, I've worked with 'Autosys', and 'Appworx'. These were robust, enterprise-ready schedulers that supported conditional execution, locks, as well as their own scripting language.