I run into this type of problem everywhere I have worked. Someone states "this is the way to do it" because they saw X% faster performance. As my group's resident "expert" on SQL, I have had to teach multiple "lunch-n-learns" on SQL performance tuning. Before this everyone based their SQL perf on how fast the query was (and sadly some still do). The problem with this was/is the test set of data is maybe 100 rows at best. In production we get at least 10-100 times that. Then they wonder, why isn't my query/view/stored proc running faster.

I also have to agree with Jeff on the hodge-podge of technologies people use. A few of our customers use a Python-scripted tool which utilizes a .Net 1.1 custom executable (source no longer exists) to import data from a flat file to a SQL 2005/2008 database. The Python experts always say its the .Net or the database. The .Net folks blame Python or usually the database. I've been forced to become, at least slightly proficient, in all of those technologies just so I can prove that its a combination of all 3.

If I wasn't willing to learn and adapt, our customer's performance issues would never get resolved (its now all I seem to do).