It's not the SQL statements that are submitted that are usually a problem. If your tables are designed correctly, in general there aren't all that many options for how to get at your data. The variations in SQL commands can cause your processes to be slower, but that's something that can be tested and fine tuned.
I think the biggest problem many developers encounter when first using SQL is not taking the time to understand normalization and having a tendency to build ugly, unnormalized tables that cause them pain as they actually try to use them. For example, there's a thread somewhere on this board from yesterday when someone was asking how to remove duplicate records, something that can only happen when your table is poorly designed.
And those of you who have taken over a database from someone who didn't know what they were doing also get to feel the pain of poor execution.
Nothing particularly bizarre stands out, except for a few really badly designed tables. Recently I encountered duplicate data, non-atomic data, miscast data types, all in a single, misbegotten table. Horrible!