I don't think that's necessarily true, hot pruning might help some, as afaict the restore happens in multiple transactions.
If we're willing to take the potential bloat to avoid a nasty complexity, then I'm all for discarding it. Jeff just indicated off-list that he isn't seeing noticeable difference in table size, maybe we're safe with how we use the function now.
But even if that's the case, I don't think it's worth using in place updates to avoid it. We should work to get rid of them, not introduce them in more places.
As the number of statlike columns in pg_class grows, might it make sense to break them off into their own relation, leaving pg_class to be far more stable?
