I just saw merlin981's comment on my LINQ to SQL post, thanks for taking time to leave it! That said, I think the term "Best Practice" is something of a misnomer here. There has been much written on both sides of this debate. One thing is for sure, though, a parameterized query is compiled just like a stored procedure on SQL Sever version 7.0 and on. From Frans Bouma's blog, I found this article in the SQL Server's Books Online:
SQL Server 2000 and SQL Server version 7.0 incorporate a number of changes to statement processing that extend many of the performance benefits of stored procedures to all SQL statements. SQL Server 2000 and SQL Server 7.0 do not save a partially compiled plan for stored procedures when they are created. A stored procedure is compiled at execution time, like any other Transact-SQL statement. SQL Server 2000 and SQL Server 7.0 retain execution plans for all SQL statements in the procedure cache, not just stored procedure execution plans.
So I think it is clear that sprocs will not be significantly faster than ad hoc SQL for simple cases. This is not to say that you should never use sprocs, on the contrary, there are situations where sprocs will be the only good solution (for instance, complex data manipulation that requires temporary tables). The point is that using an ORM can make development easier by allowing you to ignore the SQL for the majority of cases. If you see that parts of your application are slow, then you can fix that.
Merlin also mentioned that running queries directly against tables uses deferred execution like it is a bad thing. Deferred execution is what allows LINQ to work at all, and can improve performance in many scenarios. Of course, like any tool, it can get you into trouble if you don't understand it.