LinqToSql does offer benefits to corporate IT organizations.  Microsoft marketing has helped spread that message.

It's less clear what the drawbacks of Linq To Sql are, yet I believe the drawbacks are important to consider before adopting such a large disruptive change into a software development environment.

Here are some of the downsides to LinqToSql that I have identified so far:

• There is a significant learning curve.  The technology is deceptively approachable.  On the surface, for instance, LinqToSql takes a SQL Server database table and generates .NET source code for a .NET CLR class.  This appears to be a nice abstraction.  However, there is a significant amount of complexity involved.  The abstraction leaks.  Something doesn't work as you expect, so you start searching and reading and the reading seems to go on a lot longer than expected.  We are still early enough in the adoption cycle that many common issues and questions are under documented.
• There is immature documentation.  As technologies mature, the documentation improves.  This is especially true of the documentation of more obscure issues available through things like google searches.  Right now, there are "gotchas" that remain hard to find clear discussion around.
• There is a requirement for "seasoned" developers on the team.  The development team needs one or more developers who can learn new things quickly, handle significant amounts of complexity, and do the right thing without micromanagement.  These developers likely need significant SQL Server, ADO.NET, and object relational mapping expertise.  There is a limited quantity of these seasoned developers to go around.
• There is significant competition.  There are a lot of players in the object relational mapping (ORM) world.  LinqToSql, other than being included free in Visual Studio, arguably doesn't add enough value (yet) to the space.  Many of the highest traffic parts of LinqToSql can be (and have been extensively) emulated with ADO.NET.
• There is a significant amount of FUD and confusion around the future roadmap (i.e. version 2 and beyond) for Linq To Sql.  Microsoft is actively de-emphasizing Linq To Sql while maintaining that they will continue to support it for the foreseeable future.  While the Entity Framework may some day be a clear and straight-forward migration path for current Linq To Sql users, that is not the case today and Microsoft is having trouble with damage control around their confusing and mixed messages.  I wish I could link to something worth reading on this topic, but as I've said, Microsoft has really botched the communication on this issue.
• There are significant bugs.  That is a normal course of business with anything that is basically on version 1 (and since VS 2008 SP1 has been released, LinqToSql could possibly be called version 2).  Here's an example of a bug that is likely to hit a decent portion of the LinqToSql user base.
• There are significant tooling issues.  The O/R Designer and SQLMetal tools that come with VS 2008 are fairly blunt objects with fairly significant limitations.  While some commercial products have stepped in to fill some of the gaps, there are very limited free options available.  I hope to write a future blog entry with more details on the limitations in the VS 2008 LinqToSql tools (for one, see Do not use the Visual Studio 2008 LinqToSql O/R Designer).

LinqToSql will appeal to many people for many reasons and I think its momentum is likely unstoppable.

As with adopting any new technology, it's important to go in with your eyes open. 

Your mileage may vary.

Update 2009/09/16 - Here is a somewhat related follow-up blog post discussing where Linq2Sql matches up against other .NET ORMs: .NET and ORM - Decisions, decisions