Your question is spot on: when you query a view you’re still reading from all of the underlying tables. Every time. Now, you can create an indexed view which will persist the data on disk, but now you have to maintain that index. Indexed views work great for situations where your result set returns a lot of rows and needs to be aggregated. However, it is not a good idea to create an indexed view on tables that are highly transactional. This is because the database engine must maintain the index on the view as the base table data is updated, which can degrade transaction performance. Views are usually created for the following reasons:
Security - give the users access to views instead of directly accessing the tables.
Simplicity - reuse complex queries.
Intuitive naming - use to provide aliases on column names that make more sense to humans.
Subquery - the view can be bits and pieces of many tables that is treated like a single entity in a select statement.
Retain old structure - when application has schema changes, one can use views to mimic the old table structure so that any "forgotten" sprocs or adhoc queries will not break.
Views have limitations. Views cannot reference other views. They can't count. They can't select min, max, or distinct. They also can't order by, self-joins, outer joins or subquery.
You can't change the underlying tables schema.
Temp tables don't have those limitations, so that could be a big deciding factor.
If you don't have to worry about those limitations, then the decision really depends on the specific implementation. Generally speaking, if it is going to be small, then go with a temp table. If it is going to be big, you will have to test and see which one performs better.