It's not just about addressable memory. While you are correct that pointers will generally take double the memory when moving from 32 to 64 bit, storage of pointers is usually a tiny fraction of an applications memory footprint. It *may* impact how much you can fit in a cacheline if you have containers with a lot of pointers (assuming the cacheline does not double with this move, too - I'm only going by the article and it doesn't mention it). So, overall, a fairly negligible downside. Note that there should not be a difference in speed of access of a 32 bit pointer vs a 64 bit pointer (although alternate pointers in a consecutive range may see a difference, depending on how that mapping is implemented).
The upside is, at the very least: more registers (if the article is correct) - which is often even more important than the capacity of the cacheline! There is some handwaving in the article about things like "more system resources" 🤷🏻♂️ Could mean memory (but we don't seem to be close to the limit there, as you say), so there may be other benefits.
But based on access to more registers alone I'd say this is likely to be a net performance advantage for most (if not all) apps.
Of course none of this is straightforward and the reality may look quite different to my speculation, above.
What an excellent post! Thank you. Informative, and on point.