How can I prove that the following T-SQL is bad for performance?
There is dynamic SQL, so no cache plans, meaning plans generated every time


Not necessarily true. Dynamic SQL can (and does) use cached plans just as well as static SQL. For dynamic search conditions resolving to dynamic SQL is oft the right answer. See Dynamic Search Conditions in T-SQL for more details.


  There is an INSERT SELECT pattern, so table locking is more likely to be an issue.


Not necessarily true, specially with a @tempTable


  have re-written some of the Stored Procedures in this way instead


Using multiple OR conditions like that is an anti-pattern. You are forcing the query optimizer to come up with a plan that works for any value of all those parameters. Usually the only solution is a scan, ignoring any index. The original code was better.


  Can anyone offer ... any better ways of proving my suspicions?


Yes. Measure. Use a methodology like Waits and Queues. Don't relly on your intuition. Find the bottlenecks and address them accordingly.