I find it rather concerning that an article of this nature has not a single mention of the words "undefined behavior", even though that is something one has to be very much aware of when doing such shenanigans.

I don't think pointer tagging (in and of itself, when implemented correctly for a particular platform) is ever undefined behavior. Rather, it is implementation-defined behavior - the result of converting a pointer to an integer is not specified, and could in theory be anything, so you have to know how your compiler and platform behave.

What exactly do you propose such articles say about potential UB? If you are aware of UB, you are also aware that (1) it is extremely difficult (if not impossible) to conclusively determine whether such a thing is UB without retaining a language lawyer at great expense, or ending up in an infinite regress of bickering, (2) simultaneously you know that in practice, arithmetic and bit-wise pointer manipulations need to work for many intended C use cases, so it is highly unlikely that such a thing will stop working in production compilers. Perhaps this places unrealistic trust in the ISO working groups, but the only valid alternative, in my view, is to give up and go back to writing low-level code in assembly where such things have well-defined semantics.

IIUC Because C++ has pointer provenance but no explicit mechanism for tagging or clear instructions about what is guaranteed, this is basically always all Undefined Behaviour and yet in practice lots of this will work on real C++ compilers.

Today in C++ the way to avoid technical UB for such tricks will be going via an integer which is promised to have the same width as a pointer. In practice the compiler won't do anything different (types evaporate during compilation) but that isn't UB.