IMO the reason Apple doesn't provide this level of hardware documentation is because modern Macs don't have comparable expansion capabilities. The kind that expose system buses on connectors that users are supposed to plug cards into, and third-party developers to interact directly with hardware to make those cards work. On a modern Mac, you've got USB and Thunderbolt that you can interact with from a userspace program.
Though I'm not denying that some of the newer macOS APIs are very poorly documented. As in, you know you've stumbled upon the cool shit when you end up on one of those old pages with a blue gradient in the header that says "Apple documentation archive".
I think in modern environments the odds of this sort of bug slipping into released firmware/software are much lower. Address spaces are much bigger and the vast majority of addresses aren't mapped so doing a memory operation on a garbage address is going to fail most of the time, and invalid instructions will probably fail too.
Reading from a jump table with an index that's too big is a realistic sort of bug to have, so I could see that part making it into modern shipped software. But I would expect the process to fall over when it happens, not keep on trucking like it did here.
FWIW, WebAssembly is an environment where bugs of this sort are more possible, since it has a single linear address space where every address is both readable and writable. So if your garbage address is within range you can do an erroneous read, write or CAS and get away with it. But then invalid instructions like in the post will cause the WASM module to fail to load, so it's still not 1:1 comparable with this issue in the mac's ROM.
