This is all great advice, and probably apropos for this specific application.
I will however, mention one situation where the OP might have the right idea.
After quite a bit of development on our flagship site, we found we had cronjobs galore. (Over 3 dozen, I think). Cron was "managing" them ... sort of.
You see, cron itself doesn't give a flip whether one job is finished or not when it runs another, as long as it runs it at the proper time.
So, we'd end up with server loads of ungodly numbers when the cronjobs started to grow into long-running processes that were DB-intensive and cron would go ahead and start another job anyway.
Our solution: implement all crons as PHP files. Now our cron file shows 3 jobs: "daily.php", "hourly.php", and "frequent.php".
The scripts check for the presence of a lockfile indicating another cronjob has priority (if so, they sleep a while and check again, up to a max sleep value at which they just give up). When they run, they check what time it is and run the appropriate jobs for that part of the hour (frequent.php), or that hour (hourly.php), or a given day (daily.php).
The server is much happier now. ;-)