I don't really understand why you think GCs are so limited, when you are comparing them not to the runtime heap provided by a C or C++ vendor, but instead some custom scheme. To level the playing field, you should be considering a GC specialized to the purpose. There's no reason why a GC can't allocate certain things specially, or have a specified initial heap size. And GC actually makes it easier to make better use of L1/L2 cache without needing specific optimization, because caches are nice sizes to use for generations in generational GC - they're extremely quick to collect.

Saying that games and embedded systems "allocate a fixed size of memory up front and NEVER free it, re-using it instead" is almost meaningless. They are necessarily implementing their own GC or memory allocator; pretty much the definition of an allocator is something which controls how memory is reused. The only thing they've insulated themselves from is the vendor or OS's memory allocator, by writing their own allocator. This can make lots of sense when your application is all written by a single relatively small team, and has nicely understandable lifetimes for various bits of memory - games are a good example, because memory can typically be classed as existing for the entire game, a level, a frame, or a call stack. When you have such a specialized use case, it makes sense to take advantage of it. But not all, or even most, applications are like that.