Zefhemel has the right idea about language features and productivity. Noting how many extra (and complicated) language features C# had to add in order to do LINQ, he asks:

So, here’s my question. How far are we willing to drag on the huge beast that is a static language? If you look at a language like Ruby or Python, they already got most of the features that C# had to add to make this happen, but in Ruby and Python they’re not half as complicated. In Ruby you could already add methods to existing classes, anonymous methods (in Ruby known as blocks) are something a Ruby programmer breathes, anonymous types? var keyword? generics? Don’t need those.

If we want to carry on in the direction that LINQ is heading, and I think we should, shouldn’t we sacrifice this one thing: static languages? This makes things a lot simpler in many ways, and the sacrifice may just be worth it.

This was the point I was trying to make here. It's not that LINQ is a bad idea in and of itself; it's that all the cruft MS needed to add for it is. At some point, you would think that people like Hejlberg and Gosling would look at dynamic languages, ponder the complexity they've added to their own creations just to approach the same capabilities... and get a clue.