In large setups, it is usually clever to isolate job execution policy into a separate system. This simplifies a lot of contextual configuration of the system at large.
You can have cron emit the cascading event if you want but you often need a system which can "prod" other systems and ask them to do things because of a timing event. In such systems, cron often falls short as the system around it grows.
For local timing of events, cron is a really good tool however, and I wouldn't hesitate about using it there. It is for system-wide events these general job schedulers tend to help.
A tight dependency on MySQL is somewhat limiting. Have you considered making that an interface with a default implementation that uses MySQL? It pretty much ought to be a mechanical transform where you simply extract all the places you touch MySQL into a method, then write an interface around that method.
You can have cron emit the cascading event if you want but you often need a system which can "prod" other systems and ask them to do things because of a timing event. In such systems, cron often falls short as the system around it grows.
For local timing of events, cron is a really good tool however, and I wouldn't hesitate about using it there. It is for system-wide events these general job schedulers tend to help.