In my experience, some development groups tend to dislike LINQ. Of those I've encountered who don't like it or who don't want to use it, there have been 3 types. I'm primarily referring to LINQ to SQL/Entities/XML here.
First, there are those who're using other/older object management methods like CSLA or Microsoft Enterprise Library. They're comfortable with this, have time invested in it and don't want to disrupt their existing work by adding in LINQ.
Second, there are those who're more "hands on" thinking coders who see LINQ as a something a 'real' programmer wouldn't do, sort of a cheat or shortcut. One I ran into was even against using built-in generics and IEnumerable objects in favor of coding these algorithms themselves. This seems most common among ex-C++ programmers.
Third, there are those who're still thinking in terms of 10-12 years ago VB6 client-server programming even though they're coding it in C#. LINQ scares and confuses them.
I don't know if your organization falls into any of these. The first one at least holds out hope that you can move toward LINQ in some new development. You may also be able to show them some of the advantages of LINQ to Objects and get them more comfortable with it. The other two are more difficult and you'll face resistance in moving them in the LINQ direction, even in a small way.