The jocose text there is only 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
To view, as can be seen there, it is not a table of truth (unless it is materialized), it is just a way of consulting something in a simpler way, possibly already doing a denormalization and offering a form of access to certain data without entering 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 in it. It is available for queries always, until someone has it removed. Some implementations allow you to change your data by reflecting on the original table(s) (ais). The cost only exists in the normal processing of the query, which is virtually the same as the one that made manually the query entered in the view.
To top it off, the materialized view creates the physical table, but always based on an existing table(s). It may look more like the temporary table, but it always (potentially) generates different results on each result and the table is always available to everyone with due privilege until it is removed. There is cost of space and processing, even if not using it directly. I’ve seen cases where it can be upgraded independently by creating scenarios, and then it goes back to its original state, but I don’t know if it’s made for this.
Temporary table
The temporary table is physical and only exists when you have created. It is usually based on other tables(s), but it may just be something coming externally (technically as views also can, but it makes less sense). If nothing is changed in it every query applied will generate the same result. To change your data, as in your creation, you need an explicit code that you have done. Normally it is available for that session, but there is a way to make it more "permanent", even if it doesn’t make sense. It is used on demand and costs space and processing as required.
As the name says, it serves temporary purposes, something you don’t want to keep in the system, and it can even do something little related to the rest of the base, although it makes little sense. It compares a little more to the materialized vision 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, almost always it brings too much costs to compensate.
When compared to view simple with the temporary table it is easy to establish where it should be used. A view does not allow to touch it. It is a mechanism of simplification and optimization and is preferable whenever this fits.
The temporary table has more costs and implications, so you always need more justification, you have to be sure that another solution does not solve. Practically never to be used as a view. It should be used to create new data, prepare data for use in the database, create scenarios. You do what you want at that moment, you can experiment without fear, it does not make mars of your model. Treat it as a draft. Think of it as a training, a preparation for something, a simulation, something independent of the base.
It may be needed in very complex queries that depend on some manipulation in the data before it is 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 DBA does. Who does not make queries and more "normal" processing makes less sense, but can do, especially in very complex reports.
If your SGDB thinks it should it can create a temporary table to better manipulate the view, but that’s up to him, something transparent to you.
Temporary table may never go to disk.
The temporary table if "auto-excludes" at the end of the connection. The view is not a virtual table, its results are from another (s) table(s).
– rbz