The biggest being that it is a royal pain to make serializable without writing the code from scratch, negating the use of a Linq to SQL (L2S) class where you can drag and drop and link up items. Another is that I really don't see much use for L2S. I mean, I can see folks who will use it, and I have no doubt there will be large, high-profile projects where it is used, but I have yet to find someone who can justify including it for a reason.

Let's look at some of the drawbacks of L2S.

• Loss of control of how the data is retrieved.
  Ok, I've heard MS say they've got that covered, that the SQL they create on the fly will be good. But I know from experience that, as databases change and grow, there comes a time when you need to tweak the underlying SQL to make it work. If you can't, you'll run into timeouts, which does not scale.
• No virtual objects.
  If I have a table with Event entries representing a calendar, that might contain a number of detailed columns. When I present a list of these, I may just want the date and title to appear and I probably have a stored procedure that returns those two columns, maybe using some other column as a filter. If I want to do this using L2S I need to define a view with those two columns and then manually apply the sproc as returning data for that view. Where's the benefit to that?
• The really big problem with L2S is that it is compiled. If I discover a problem and need to change a join that L2S has created, I need to modify the code, compile and redistribute. Web apps may not be that problematic, but desktop apps scattered among a few hundred (thouand?) desktops can be a major headache.

Yes, if I was prototyping an app, it might be a short hand way to do it, but the problem with that is too many of those prototypes end up in production.

I can't see that it provides any benefit in speed outside of the development process. 

But that's my rant. As always, YMMV.