Linq is an opportunity to write slow code very quickly. Of course when you have to spell out a 1-line Linq expression as a 50 line method, you'll notice that you wrote a triple nested loop and avoid it. But the point is this: the longer code is MUCH harder to comprehend than a concise Linq query, and the developer that didn't see that their Linq query was going to be slow wouldn't have reacted on that the expanded version also looked slow. The single line query can be more easily refactored as it can be comprehended.
So I say write slow code so you can find what's slow early on. The problem is likely to be in the architecture and data structures rather than in the processing code. If Linq gives an opportunity to deliver a working example quickly, and that example shows that for large N the perf is horrible, then Linq was extremely useful! Change some collection type, demoralize something, add some caching etc. and then slightly adjust the Linq query to suite. Large query methods are inertia to such changes so when they DO become necessary it's a larger effort.
Note that I mean Linq to objs now not Linq to Sql or some other provider.
So I say write slow code so you can find what's slow early on. The problem is likely to be in the architecture and data structures rather than in the processing code. If Linq gives an opportunity to deliver a working example quickly, and that example shows that for large N the perf is horrible, then Linq was extremely useful! Change some collection type, demoralize something, add some caching etc. and then slightly adjust the Linq query to suite. Large query methods are inertia to such changes so when they DO become necessary it's a larger effort.
Note that I mean Linq to objs now not Linq to Sql or some other provider.