That's a pretty good explanation.
You can do all game calculations two ways, independent of the framerate, or synced to the framerate. Console games used to (and may still be) synced tightly to the framerate, so gameplay actually changes if framerate changes. PC games moved away from that a long time ago, so generally graphics and lighting are unrelated to AI, gameplay, and physics.
If code that's relevant to gameplay slows down, you either get a change in gameplay, or the game actually slows down. The latter is preferred, but it's rare you'll see a game's speed actually show down besides rendering framerate.
Game calculation speeds can be uncapped, uncapped up to framerate, or capped at some arbitrary rate. In the case of Nvidia Physx, it runs at its own simulation speed apart from the rest of the game, although few if any games use it in a way that effects anything other than visuals. I imagine this is because of the intended use scenario, where Physx is calculated on a separate graphics card, so it's hard to tightly couple the physics simulation with the rest of the game. A cpu only physics engine would be easier to couple to gameplay since there's no communication penalty.
As another example, many strategy games run the gameplay on a separate thread from graphics. So it's quite common in a game like Civilization to get 60fps, but have the simulation speed be very very slow.