Ian Griffith pointed out ages ago that the ‘LINQ’ abstractions can leak.
And when it leaks it leaks badly, leaving you with no clue.
Another point to consider when doing you nice fit-n-finish project with LINQ is how are the queries managed. Usually, we organize our n-tiered projects into having a data-access layer at the bottom. At this layer, all the queries are concentrated with whatever that needs to be searched, inserted or updated must go through the services provided by this layer and not in any other way. This means that you can usually pin point any data access problems to this layer and be done with it pretty quickly.
Specialized tools may even generate a large part of the code involved, with everything from table mapped classes to associated views, stored procedures etc.
All this is very fine organization, which is lost if you naively start using LINQ all over the place. One way to circumvent this is to place all your LINQ statements in a separate static class, and access them through static functions or as instances of delegates returned by System.Data.Linq.CompiledQuery. But this has one serious limitation, queries are limited to taking only four parameters at this time and there is no way to extend that support even by new extension methods feature.