Wouldn’t it be a huge overkill to run your own temporal or airflow instances just to run your cron jobs? Just curious.
There are certainly use cases for which it's more than is required. Like the most simple would be adding a cron string to a GitHub Action or Vercel function, but in most cases, and certainly Slack's case, you want more reliability, scalability, flexibility, and/or observability. And Temporal has extreme levels of those things, including pausing & editing schedules and seeing the current status of all triggered scripts/functions and all the steps a function has taken so far, and guaranteeing the triggered function completes, including ensuring that if the process or container dies, the function continues running on another one. Even if you don't care about all those things, you might care about some of them in the future, and it doesn't hurt to run a system that has capabilities you don't use.
Workflows are not zero-cost, they have their own tradeoffs compared to microservices. State management / bootstrapping logic becomes non-trivial, execution order though easier to visualize is also slightly not deterministic, workflows are not as well suited for request-response style replies due to the latency involved in total execution etc (but I think they are great alternatives to async / background workfllows) - and shared underlying infrastructure means increased chances of SPOFs.
The state must have improved much since then. Also, adoption of anything new to require remodelling your application into a different paradigm must be worth the value delivered. For example, modular monoliths became popular because they reduced operational complexity by reducing # of pieces involved. At the time, that value prop vs effort involved was unclear to our teams IMO