Games are multithreaded and have loads of objects running everywhere. If you're using anything that's not a custom game engine, there really isn't a single main() function that you can plop an if statement like that into.

Slowing down time applies it universally. Otherwise you're going to need that condition to every single object in the game.

It's usually not as simple as that. You'd still want to at least keep the UI alive, and you also need to continue rendering while the game is paused because the swapchain surfaces might lose their content (window resizing, changing the display mode, alt-tabbing to the desktop etc).

E.g. when you open the ingame menu, the inventory (etc) you usually want to pause the gameplay, but still want to interact with the UI. Sometimes that means that at least also some of the gameplay logic needs to remain alive (inventory management, crafting, levelling up, etc...).

There are also a lot of games which need some sort of 'active pause', e.g. the gameplay needs to stop while the user can issue commands to units (traditional example: real-time combat with pause like in Baldurs-Gate-style RPGs).

Sometimes the underlying engine also doesn't properly separate gameplay logic from rendering, e.g. you can't skip one without also skipping the other (which is an engine design bug, but similar situations may also happen up in gameplay code).

Finally: pausing and the save-game-implementation is often an afterthought, but really should be implemented as the very first thing. It's quite easy to run into the trap that a frame also needs to advance time. If the game has the concept of a fixed-duration 'game logic tick' which is independent from the frame rate you're already halfway there though, but many games simply use a variable-length game tick which is identical with the frame duration.

The slowing down thing sounds like a hack needed for engines that don’t give you control over the main loop.

I haven’t tried this yet, but for a custom engine I would introduce a second delta time that is set to 0 in the paused state. Multiplying with the paused-dt „bakes in“ the pause without having to sprinkle ifs everywhere. Multiplying with the conventional dt makes the thing happen even when paused (debug camera, UI animations).

It depends on how your timers are implemented. If they are implemented as a "rendez-vous" absolute date (as in UTC for instance - not in local time unless you want to add "eastern eggs" related to daylight saving time...), this will cause bugs. If you implement your own in-game monotonic clock that you can stop, it should be ok.