[...] It is on critical path, so every check increase computer time for transaction end.
Hmmm... Everything executed is on the critical path...
It is a very good thing that GUCs are transactional, and this should not be changed, it is a useful feature! Much more useful than non transactional.
Personally, I never used - although I using often nesting
Your position is contradictory:
First you put forward a variable-with-permissions for a special use case, you insist that correctness is key and must be checked with static analysis tools that audit codes, that dynamic variables are too ugly for the purpose. Fine, even if I disagree with some details, there is some logic in that: security, audit, checks... why not.
Then when one shows that correctness requires that the variable is transactional, this is not so important anymore based on the fact that some big companies do not do it like that, and suddenly it is enough that it probably works sometimes. And when the fact that pg already supports transactional variables is pointed out, just what the use case needs... then you suggest to remove the property.
The GUC are designed for different purpose - I don't know why somebody did there transaction support - I understand and I remember the nesting support.
look to code - the GUC related code has more about 10K lines, probably 5K lines is important for this purpose.
There are more reasons, why I would not to use GUC
0. it is not designed be secure - there is different security model - readonly, superuser, others
1. it is dynamic - not persistent - cannot be used as package variables simply
2. there is different placing - custom requires prefix - I prefer using our schemas, because schemas are used in pg like packages in Oracle
3. large number of GUC decrease performace of end of transactions, subtransactions
4. any RDBMS using untransactional variables - it should be default optimized behave
