Anonymous methods, unnamed classes, try catch blocks are all examples of these type of tools that when used improperly will kill the system performance, code readability, maintainability and extensibility.
We are specifically talking about C#. LINQ was specifically held as one of the improvements to the language. I am not quite sure what your point is relative to that.
There are shockingly few examples where LINQ is superior to alternatives. LINQ is the brute force technique of avoiding proper collections/algorithms.
Maybe you're refering to LINQ-to-whatever (LINQ to SQL, etc.), a LINQ generalization where you can quote your expressions, rewrite the AST and emit something else (a very constrained kind of macros, if you will).
MS is probably to blame here, but people keep conflating the two.
Take a block of code with LINQ in it and rewrite it minus LINQ but logically performing the same operations that the sugar is resolving to. To most developers it would offend the sensibilities of construction, but somehow in LINQ-land all seems fine.
What LINQ does is make your code more concise and readable. It makes it easier to find bugs and easier to understand by someone else (even if someone else is you, 6 months down the road).
It also just takes a lot less time to write.
So when you want to sort, search or transform a list, you prefer a technique which doesn't iterate over the items in the list at all? That makes no sense.
But I don't agree that LINQ is bad because someone on your team didn't know how to use a Dictionary and thought that iteration would be fast on large in-memory lists.
In many cases there are efficient LINQ constructs, e.g lazy lists, and First() not enumerating past the matching item. Hand-coding these is prone to doing it worse than Linq would. Teach your team how to use .ToDictionary() if need be.