The security argument against using DDLs is neither completely wrong nor completely right.
If a web service is compromised, and an attacker manages to issue arbitrary
delete statements, the damage they can cause is not really different from the damage they can cause by a
drop table or
modify table statement. Ok, when you system allows installing of new stored procedures or other forms of executable code by DDLs, an attacker might cause more damage than just by destroying or extracting some data, and it is probably a good idea to forbid such DDLs.
But with or without DDL access rights, the countermeasures to make a system robust against such attacks are 100% the same:
be extremely careful with dynamic SQL, and make sure only statements prepared by you can be executed, with properly validated input parameters
have regular backups in place
keep your system up-to-date with regular updates
When the system was successfully attacked, you will usually have to make a full restore of the system, including data and DB schema. If an attacker had no execution rights for DDL statements, I don't think any professional DB admin will try only to restore the data based on that information, they will usually restore the whole database anyway.