It's not so simple though. Would you rather see a dynamic select query that joins 2 tables and has 2 conditions in a WHERE clause (because other parameters are nulls) or would you rather see a SP with 16 joins and 16 conditions, like that:

AND (@CustomerID IS NULL OR tblX.CustomerID = @CustomerID )

I have seen the second and I am sure the first (dynamic query would be faster). SQL Server will cache execution plan for a dynamic query too.

Also, I have seen SPs that cached execution plan but that plan was causing other executions of the same SP (with different parameters) to be very slow. I had to use WITH RECOMPILE to make SQL server not to store the execution plan.

Some code generators create SPs and some create dynamic queries. Which way is better will depend on the amount of data being processed, on application characteristics etc...

I would think that you would need to learn more about the application to be able to judge possible impact it would have on the DB that you take care of. There is no rule that says: SP is always better than a dynamic query.