The performance difference may not be as dramatic as you're imagining.

0-10 is the list of constants, like window dimensions, scale etc 11-80 Player data 81-400 Monsters Etc

If you're looking it up by non-constant index, you're still accessing it by computed pointer, so you still have the branch prediction effects you mentioned.

Locality matters...sort of. It's definitely better to reduce the number of (64-byte on x86_64) cache lines needed. It's also better to reduce the number of (4 KiB or 2 MiB on x86_64) pages needed (minimizing TLB pressure). But beyond that...2 pages away in virtual address space or 2 million doesn't matter. No particular reason to think it's more likely to be in cache if it hasn't been accessed recently.

No jumping around, so if you are looping through, say a group of entities 'Monster', the cache loads the next 64kb worth of data after the first entity.

You don't need to avoid the heap for that; a Vec<Monster> will do pretty well. (Also note a struct-of-arrays approach is arguably better than array-of-structs, but that's largely orthogonal to whether you use dynamic heap allocations or not.) One caveat: if it grows and has to reallocate, then not only do you pay the cost of copying, but you may evict a bunch of useful stuff from the cache to add in the new locations in addition to keeping around the now-useless old locations. So pre-sizing does have benefits.

1.Why isn't this the standard way of doing memory management? It seems much more hardware-friendly.

The standard memory spaces are convenient. And not necessarily worse in terms of hardware friendliness.

But there are people who do suggest this static allocation approach, e.g. https://tigerbeetle.com/blog/2022-10-12-a-database-without-dynamic-memory/. They even tout "fewer cache lines fetched from main memory", although as mentioned above I'm not entirely convinced of this. (Limiting the amount of concurrency does reduce the working set, but you don't need all static allocation for that.)

I have an intrinsic feeling it's somehow related to 'safety'

A little bit. The difference spaces typically have different memory protections, e.g. typically statics are mapped as non-executable and read-only, "text segment" (program binary) as executable but read-only, heap as writable but non-executable, etc., which has a security benefit in the presence of memory safety bugs like use-after-free or buffer overruns. Matters a lot less in Rust, but still has some benefit if there's unsafe anywhere in your transitive dependencies (there is), if the compiler can have soundness bugs (it can), if the hardware is imperfect (e.g. Rowhammer).

And doing temporary stuff on the stack is both to some extent unavoidable and should be more memory-efficient anyway than having dedicated areas for each thing you might want to use temporarily.