I read your comment and the article and I’m still not really clear on why this isn’t as simple as saving the current state or pausing the render or time loop.

The short answer is: because of all the complexity that you're not seeing. I'll try to explain:

My '1983' example above is a simple way to implement a pause state -- when the game is paused, don't run the game logic. The sprites disappearing that I described (a real quirk, if not a bug, of games of that era) is a side effect of that. The sprites disappear because the set of objects to draw each frame is determined by the game logic, which is being skipped in order to pause the action.

Is it wrong that the game logic submits the drawables? I would say that it's inflexible, but not wrong. After all, the sprites are representing the state of the game, so they must be derived from it in some way.

You can do more engineering to support a more robust & elegant pausing system. You can build that system such that pausing the game feels like simply "pausing the loop". But that's more code, more complexity, less simple.

I'm not exactly sure what "pausing the render loop" means to you, but let me ask you this: how do you render the pause menu? When there is no time passing, how does the little bouncy cursor in the menu continue to bounce?

You'd want sound effects to pause while the game is paused, and ideally resume from where they were when the game is unpaused. But does the pause menu make sounds? Is there music? Does the pause menu play different music or continue the in-game music?

And this is the most obvious, simplistic idea of what pausing the game is -- to show a pause menu. What about in-game cutscenes: do the NPCs in the background keep running around while you're talking to another one? Inventory management: the items the player has are a gameplay system but you access it while the game is paused?

This pattern applies to every system in the game. You can't just cut out the xyz altogether, you need a sufficiently complicated xyz system in order to simply pause what you want to pause.

Saving the current state? What does that even mean? You don't save transient things like visual particle positions but it's something you expect to persist between pauses.

Pausing the render? But not the physics so you keep falling? You need to pause many systems. At the very least you'd want to pause gameplay, and sound and physics. You'd want to keep input and some of the UI unpaused. If you have a fancy UI with VFX, you need to make sure those are not using the paused game time. etc etc

It’s only simple if your state machine has zero implicit state and all transitions are perfectly and precisely articulated. Good luck with that!

P.s. And once you are done achieving the above, you can then make sure you haven’t caused performance issues :)

But yes, conceptually, it’s a relatively simple idea. The devil is always in the details.