What are the major pitfalls that would make you think twice about using LINQ to SQL in an enterprise/non-trivial system?
I know it lacks the power and flexibility of NHibernate, but I'm not clear on the major reasons why you wouldn't want to use LINQ to SQL in an enterprise app.
Changes to the model appear to be handled in a very clunky manner under LINQ-to-SQl. To some extent, this is an issue for many code generating tools; however, for the good ones there are sensible ways of dealing with this. There are some hackish sort of ways of dealing with this with LINQ-to-SQL, but I wouldn't call them "enterprise ready." The designer experience is a bit lackluster for large, non-trivial systems. Also, it essentially being phased out in favor of the Entity Framework. Personally, I prefer LLBLGen.
It has some pitfalls, but at the current time, I have many reasons to suspect it is more enterprise-ready than Entity Framework is. However, the changes in EF/VS2010 should (hopefully) rectify this. If it doesn't, they've probably blown their chance.
The biggest pain point (for some people) with LINQ-to-SQL is the "SQL-Server-Only" restriction. This isn't an issue for me, so I like LINQ-to-SQL. The simplicity, and the support for things like UDFs and query-expression re-use* are great.
Note also my comment re the "scrapping" of LINQ-to-SQL on the other reply. MS has re-iterated very publicly that LINQ-to-SQL continues to be a supported part of the .NET framework. It still has a development team and active development (I've seen the former recently, and seen evidence of the latter).
*=i.e. Expression.Invoke, not very well supported in EF but hugely useful in LINQ-to-SQL
Only if the system needs to support other than ms sql server.
Other than that, it is about understanding its limitations and where not to use it (or complement it for that matter). Bulk operations aren't well supported, either to get large volumes of data into sql (you use something like sqlbulkcopy) or to do operations against a range of pre-existing rows in the db (i.e. an update ... where ...). There are custom third party implementations for the later though.
One real/ugly gotcha is that it doesn't plays well with tables that don't have a primary key, if they don't on the db you must set it on the designer or you are on for some really ugly+weird behavior. The worst part of it are updates fail silently if no primary keys are defined (can be in the designer), as entity tracking is off for those.