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.