I've seen this strategy appear before in real-time situations where new allocations remain in a near-constant band: As long as you have enough memory to make it through one loop, you could use it as the defining strategy of your game engine or signal processor, at least w/r to temporary allocations.
I've also heard of GC algorithms using exactly this behavior for the nursery stage.
From a user standpoint, when we speak of "cartridge" we're talking about the packaging - 8-track tapes were also called "cartridges". Calling any game cart "ROM" has been a little bit off in that old cartridges were PCBs that could contain arbitrary chips, custom hardware, battery-backed RAM, etc.
With the modern carts, it's all flash memory - both the game binary and any user data can coexist. That said, it's much less common than in the NES era, but not unheard of, to incorporate custom hardware on the cart. For example the DS Game Card[0] has an infrared variation. With this change the overall performance model now is guided around working with flash memory - you have big mass storage, longer load times, and don't get to do any fancy bank-switching tricks or rely on an additional co-processor or an extra RAM bank.
I've also heard of GC algorithms using exactly this behavior for the nursery stage.