I think it was more the extra layers of indirection added to function environment\effectively global variable access added in 5.2 .
The removal of scanning for changed userdata finalizer meta method in 5.2 is just a commonsense fix for bad design that made GC atomic phase run time, thats not incremental scale up with the number of GC userdata objects alive no matter if they have a finalizer or not.
There is work being done on Git to add pluggable object backends[1] by some GitLab devs that could changes things up a bit and make large object handling not suck Maybe Lore could act like a promisor remote to pull large objects from as well for interop.
Part of Windows Explorer actually does tons of tiny 4 byte ReadFile calls in to its tracking database like file when you delete a file. If you deleting lots of files this quickly adds up.
I think they just swapped out LuaJIT's modified built-it dlmalloc[1] with some standard allocator. Then just set some turning values of the allocator to make to more eager to return pages with no allocations left to the OS.
LuaJIT has always had pluggable allocator system you can set at state construction time[2], it did have a restriction you could only use the built-it allocator for 64 bit builds if you don't use the GC64 build option, but thats been default enabled for a while now.
Someone already created that[1] using custom kernel driver and there own CDN, but they seem to of abandoned it[2], maybe because they would of attracted Valve's wrath trying to monetized it.
There was commercial fork of clang zapcc[1] that did caching of headers and template instantiations with an in memory client server system[2], but idk if they solved all the correctness issues or not before abandoning it.
AMD also switched to 16k(4 x 4K) down from 8 in Zen1 for there PTE Coalescing system that is effectively run length like compression of page table entries with sequential addresses in to one TLB slot.
You can sort of do that with some of LLVM's JIT systems https://llvm.org/docs/JITLink.html, I'm surprised that no one has yet made a edit and continue system using it.
I personally just went down the route of stripping down the FFI system when integrating LuaIT. It included things like removing the ability to define new ffi types\functions or loading libraries, as well as removing most casting and pointer indexing.
That binary search benchmark probably triggers a trace explosion in LuaJIT like I've found quicksort does. If your lucky the function gets trace blacklisted, if not it ends up hitting the default max number of traces and throwing away all the JIT'ed code and repeating the same thing over and over.
Its a book https://whenitsready.com/wowdiary/ originally sold as a kickstarter by one of the original Blizzard mappers made from notes they wrote while working on original wow. They did some AMAs[1][2] with other wow developers that sort of touch on some of the topics discussed here.
At least AMD kept AVX-512 in there small Zen4C cores and just sacrificed some cache instead. I have to wonder if it was intel marketing that killed off working AVX-512 in consumer P-cores after they were released because the E-cores just become dead weight with AVX-512 enabled.