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.
Yep, this comment does a good job of illustrating the (surprising) complexity of this.
I'll add that the notion of the "time scale" variable as mentioned in the article is something that's only solidified/codified since Unity and the like came about. And at the same time, the way Unity et al. works[0] doesn't really encourage thinking about what I'd call "main loop logic" in the bottom-up way that's required to build a really robust system for managing states. You can do it, of course, (you can write as much code as you want) but by default, everything in the scene is "active" and somewhat independent from everything else, and you don't have direct control over the various major systems.
[0] I guess I should say "worked" -- I mostly used 3.x and a little bit of early version 4 -- I'm sure it's improved but I wouldn't expect anything drastically different.