If you want to ignore performance, there are things you can do with non-transactional variables that are simply not possible with tables. But even ignoring that, the performance cost of temp tables is massive compared to variables.
Ok, then read "variables are like tables" instead of "variables are tables". Note that I'm definitely interested in performance in the end, but I'm first interested in discussing features.
Currently I'm unconvinced by a proposal of variables that are in the relation namespace (pg_class), are subject to GRANT/REVOKE, are managed with CREATE/DROP *but* are somehow partly non transactional, and only alive through sessions, and are only accessed through functions...
My current thinking is that the proposed design is either too heavy (pg_class, permissions) or too light (then why not possible persistence and/or transactions?): I would be more at ease with very light-weight typed? session variables stored in the server process "as is", without any attempt at pg_class & permissions, or with more full featured variables, but not something half-baked which seems designed for a particular use case that I do not have.
Not only is the access far more complex, but bloating is a major problem (both in the table itself as well as in the catalog). That's part of the driver for all the discussion about things like permanent temp tables (which still leaves a bloat and performance problem in the table itself).
If a variable as currently discussed is in pg_class and subject to permissions, then probably it will cost on the catalog side anyway, and at least their existent would be transactional even if their value is not.
the access right check has **constant** small cost (check in object cache). The proposed variables has not any negative effect on catalogue bloating because a metadata are persistent.
It is reason why I use statement "CREATE VARIABLE", not "DECLARE VARIABLE"
