One role in which views are naturally suited to is for customizing data sources to bind to server controls in a Web Form. Specially so when the data needs to be retrieved or pre-processed from multiple tables or other views.
Consider the following master/details scenario, which is typically resolved using data in related tables. Alternatively, views can be used to dynamically provide the data sources for the master and details grids, as shown in this example.
A view by itself cannot accept parameters in its definition. Still, they can be used within parameterized queries, though this may (arguably) offset the performance advantage offered by saved views.
Anyway, the following example illustrates using views to query only values of interest. Assuming all other factors that affect performance are optimal (link speed, server configuration, database design, application design, etc.), any overhead associated with querying a view is practically nil.
In addition, SQL Server™ includes a query optimizer that executes queries in the most efficient fashion possible. However, while SQL Sever™ uses the most optimal access plan, this is limited by what is fundamentally possible. If a query is inherently resource intensive due to improper constructs, no degree of query optimizer intelligence can change that.
For more information on query optimization, see Execution Plan Caching and Reuse under Query Processor Architecture in SQL Server™ Books Online.