Too bad they didn't ask any VR developers. It's truly another beast, especially if you're developing with Unity for the Quest platform, since setting TimeScale to 0 in Unity effectively disables the physics engine, which means things like hands/controllers no longer work, which then breaks one of the requirements to even be able to release in the Meta store (handle pause state). The workaround used by Half-Life: Alyx (as told to me by the Hurricane VR developer when I asked years ago how to deal with pausing) is to clone your hands and disable/delete all physics-related stuff (e.g. Rigidbodies) on the new "paused" hands. If you are using laser pointers, then you'll also have to switch those out as well. If you have any active effects, particles or objects that obstruct the player's vision and/or visibility of the pause/resume UI, then you'll want to either disable those out or at least dim them substantially so the player can interact with the resume button e.g. with a laser pointer. You might also want to adjust the lighting to indicate that the user is paused.

Outside of VR, Unity offers a nice "AudioListener.pause" to pause all audio, but if you have any sound effects in your pause menu like when a user changes a setting, those no longer work, further requiring more hacky fun (or just set it to true, and ignore user-complaints about no audio on menus when paused).

On top of that, you have things like Animators for characters, which also have to be paused manually by setting speed to 0 (TimeScale = 0 doesn't seem to do it). Some particle systems also don't seem to be affected by TimeScale. If you have a networked game then you also have to (obviously) send the pause command to clients. If you have things in motion, pausing/restarting the physics engine might cause weird issues with (at least angular) velocity so you might have to save/restore those on any moving objects.