Access makes every effort to make every query a pass through query. That doesn't mean you will get identical performance but in most cases, you won't be able to distinguish a difference UNLESS, you have used something in your Access querydef that prevents ODBC from sending the query directly to the server.
Views would not logically be faster than tables. However views that join several tables might be faster.
Tables/views that have useful indexes will always be faster than those without, unless of course, you don't use criteria.
And that leads us to what the others have said, to get the best performance from your Access FE, you want the SQL Server BE to do the heavy lifting and so therefore, you ALWAYS want to use criteria in the bound RecordSource query AND you want to limit the columns selected to only those you need so no queries of "Select * from tableA" should ever be used as the RecordSource.
I've been using Access as a FE since the early 90's. Originally against IBM's DB2. Mostly these days it's SQL Server or occasionally Oracle. In ALL cases, I use bound forms/reports and Access querydefs. If something is slow and I can't fix it with an index or an updateable view, I will look into other options. The key is always limiting your data selection to the absolute minimum. It is better to go back to the well 25 times or even a hundred during a session than to bring down 50,000 records and filter locally. The larger your tables, the more important this concept is. Also, be aware of the VBA functions that have direct translations to T-SQL because anything else will have to be processed locally. If your UDF or VBA function is in the Select clause, that's not a big deal, Access brings back the requested record and then applys your function locally. However, if the function is in the where clause or order by for example, you force Access to send the query to the server with no criteria and then perform the selection itself locally.