The jocular text there is just because there would be many subjects:)
In fact they have nothing to do, they are very different mechanisms for very different purposes, with different commitments.
view
The view , as can be seen there is not a real table (unless it is materialized), it is just a way of consulting something in a simpler way, possibly already doing a denormalization and offering a way to access certain data without entering into others for a user that you do not want to expose all of the table (s) used in the view . The data is always generated from existing real tables and the specific result is available for this query. Each query in it can generate a different result without doing anything on it. It is always available for inquiries, until someone has it removed. Some implementations allow you to change your data by reflecting on the original table (s). The cost only exists in the normal query rendering, which is virtually the same as doing the query entered in the view template manually.
To complete the materialized view creates the physical table, but always based on existing table (s). It may look more like the temporary table, but it always (potentially) generates different results in each result, and the table is always available to everyone with due privilege until its removal. There is cost of space and processing, not even using it directly. I've seen cases where it can be updated independently and can create scenarios, and then it returns to the original state, but I do not know if it was made for it.
Temporary table
The temporary table is physical and only exists when you have it created. It's usually based on other tables, but it may just be something coming externally (technically, the views can also, but it makes less sense). If nothing is changed in it all applied query will generate the same result. To change your data as well as your creation, you need an explicit code to do so. Usually it is available for that session, but there is a way to make it more "permanent", even if it does not make sense. It is used on demand and has cost of space and processing as needed.
As the name says it serves for temporary purposes, something you do not want to keep in the system, and may even do something unrelated to the rest of the base, although it makes little sense. It compares a little more to the materialized view because both are physical. But the temporary ones are for extra operations apart from the normal operation of the base, the materialized ones are optimizations to the normal access of the base.
When to use each
It's rare to need materialized view , it almost always costs too much to make up.
When you compare simple view with the temporary table, it is easy to establish where it should be used. view does not allow you to move it. It is a simplification and optimization mechanism and is preferable whenever this fits.
Since the temporary table has more costs and implications, then you always need more justification, you have to make sure that another solution does not solve. It should almost never be used as a view . It should be used to create new data, prepare data for use in the base, create scenarios. You do what you understand right then, you can experiment without fear, it does not do mars of your model. Treat it like a sketch. Think of it as a workout, a preparation for something, a simulation, something independent of the base.
It may be necessary in very complex queries that depend on some manipulation in the data before they are used.
The temporary table is a normal table and can do everything with it, including creating indexes.
DBAs tend to use this more than developers. It makes more sense in procedures or complex processing that only the DBA does. Those who do not do "normal" queries and processing make less sense, but can do it, especially in very complex reports.
If your SGDB thinks you should, you can create a temporary table to handle the view , but this is something transparent to you.
