I've been working with Linq-generated SQL for a while and have definitely had similar experiences. When the queries are straight-forward selects on a group of tables with simple joins, then you'll generally get adequate performance.

If you're working with more complex business objects where you're looking at many tables and/or views, then the nesting and joining of objects can become inefficiently large and complex.

A big weakness of many ORMs is their propensity to SELECT * from any entities they query, which can be a huge performance hit for SQL Server as it will always be retrieving far more data than it needs.

I would definitely recommend creating views for simple sets of joins that will be relatively stable, and stored procedures for more complex business logic. This is your only way to gain control of the SQL you are working with to ensure performance is adequate.

One last note on Linq---if a query is not parameterized, then it will be more difficult to track performance as each query that is executed will likely have a different execution plan (unless they are identically written).