If you're 100% sure you always prevent SQL injection everywhere, this indeed is nonsense.

However, SQL injection is one of the most common security risks, and even if you're sure you've properly written your application to use parameters, a sloppy DBA might execute a query that's at risk for second-order SQL injection. It might not even be stored anywhere, it could just be a query to copy a table.

Second-order attacks are harder to execute, but harder to protect against. Protecting against second-order attacks means that every SQL statement ran on the database needs to be checked for a risk of SQL injection.

Disallowing quotes everywhere is a sloppy protection against second-order attacks, but does make them less likely. In an ideal world it wouldn't be necessary, but unfortunately we aren't living in one.

If many users have any form of write access on the database and are able to write their own SQL statements, it might be a sensible security measure. If your application is the only way to access the application, and only very knowledgeable users can execute their own queries with write access, it's typically not necessary.

If you're 100% sure you always prevent SQL injection everywhere, this indeed is nonsense.

However, SQL injection is one of the most common security risks, and even if you're sure you've properly written your application to use parameters, a sloppy DBA might execute a query that's at risk for second-order SQL injection. It might not even be stored anywhere, it could just be a query to copy a table.

Second-order attacks are harder to execute, but harder to protect against. Protecting against second-order attacks means that every dynamic SQL statement ran on the database with write permissions needs to be checked for a risk of SQL injection, not only SQL statements that process input from untrusted sources.

Disallowing quotes everywhere is a sloppy protection against second-order attacks, but does make them less likely. In an ideal world it wouldn't be necessary, but unfortunately we aren't living in one.

If many users have any form of write access on the database and are able to write their own SQL statements, it might be a sensible security measure. If your application is the only way to access the database, and only very knowledgeable users can execute their own queries with write access, it's typically not necessary.