A lot of the article talked about swap which wouldn't be a concern in normal operation of most production servers--cache/memory locality still matters but not as dramatically. Back when I was managing bare-metal MySQL servers we were getting scaling to NUMA memory (with jemalloc/tcmalloc). There was an initial performance degradation that required a lot of fine-tuning even working around how the same motherboard/CPUs would initialize core affinities differently. A new problem was deadlocking of large transactions that touched multiple buffer instances. Mind you this wasn't a clean codebase that put a lot of thought into avoiding deadlocks (up until then).

At the time I didn't think much about how the allocators could help as they're constrained to the ABI. Writing in Zig with custom allocators for everything would. The only mysql NUMA setting was innodb_numa_interleave=ON which wasn't very good but not a lot worse than trying harder.

Much of that is well addressed by one allocator arena per cpu, and either pinning threads to cpus or at least having a high threshold to move threads across NUMA boundaries.

If you have a lot of cross thread memory use, maybe you need something to help with allocate on core X, free on core Y and the cross core communication that causes (maybe that's already in place?).

There's more memory overhead that way, but large core count systems tend to have a lot of memory too.