But that is where the similarity ends. The create does not really create a physical table, as the table is only created when used. These tables only exist for a unit of recovery, that is they are alive for a commit scope. Any references to the table are to a unique instance of the table for each application's thread plus connection. There is no locking, logging, and recovery for temporary tables.
Many applications require relational tables to be used as scratch pads for a transaction.
That is one use but perhaps another more important is the ability to take data from non-relational data stores or real time event messaging, and move the field elements from those into rows and columns of a temporary table. Then use the temporary table in joins and nested table expressions, yielding relational result sets required to answer a business need. A classic example is when new systems are built based on DB2 and older legacy systems still exist, but the data needs to be related. This seems to be very common today and now it will be easy to join the data in a legacy VSAM file and a DB2 table. Perhaps just as significant would be the ability to move other data into a DB2 table where sophisticated logic and filtering can be applied during a join process.