Since LINQ to SQL basically is a layer on top of ADO.NET it requires some translation. Does this mean that using ADO.NET directly is faster than LINQ? Or is the difference so small that it is irrelevant?
It does mean that ADO.NET is faster. It also gives you heaps of more freedom to optimize your SQL queries (well technically, you could use LINQ to SQL with stored procedures only, but you'd miss out on the whole point).
The fact is that if you really really really need to optimize for best performance, then nobody really recommends using an OR/M. There are heaps of considerations with OR/M:s, performance-wise. But a lot of sites do not really need to optimize that much for performance, in much the same way that we can afford programming in .NET rather than assembler, even though that is the same kind of overhead as compared to writing code in a lower level language.
The point of using LINQ to SQL or NHibernate, or really any other OR/M is that (as with the .NET analogy) it'll give you a whole lot of convenience, and it'll save you a lot of time developing, and make refactoring and other later changes a much simpler task.