There are valid reasons to store SQL in a table. Software I work with at work now includes a system for generating documents and the documents need to include fairly complex calculations using data in a database. The documents are updated frequently, are often significantly different in terms of the data needed, and the calculations that need to be performed. SQL is being used, basically, as a scripting language for performing these calculations and that SQL is stored in tables that also store other info for these documents. The people that maintain those documents are not programmers or DBAs, but they're familiar with the database schema and they're proficient with SQL. It would be significant overhead for them to maintain that SQL code in the form of stored procedures.
For what you described – "... a project that will require quite a few cron jobs that will execute SQL statements periodically" – the other answers are probably correct in suggesting that you used store procedures, or the equivalent, for the DBMS you're using.
A good criteria for deciding whether it's sensible to store SQL in a table versus in a stored procedure is determining who will be maintaining that SQL. If users maintain that SQL, i.e. they write it and change it whenever they want, then it may be perfectly fine, and indeed best, to store that SQL in a table. If developers will be maintaining that SQL, then it should be stored in a form that can be updated by your (hopefully automated) build and deployment procedures, e.g. stored as an object like a stored procedure in the database itself.