A lot of games have some internal "physics rate" or similarly termed tick rate at which the logical state is updated. The better you can decouple the graphics pipeline from it, the better.

Not anymore, in the past it was. Some games in the 8bit world ran slower in Europe vs the US because Europe TVs used PAL which was 50hz refreshes, while the US had NTSC with 60hz refreshes (some games counted on NTSC being interlaced and so updated at 30hz which made NTSC games slower). IIRC some PC games depended on frame rate as well, but I don't recall any specifics.

Skyrim infamously allows your frame rate to influence game physics, with hilarious results.

https://old.reddit.com/r/skyrim/comments/twwqqt/can_someone_...

This is one of the traps when you go for the naive approach to framerate independence: simply using the frame delta for stepping your calculations. Results for physics engines are very wacky! It's usually better to step your physics engine at a fixed rate (e.g. 60hz), and make the frequency of steps performed independent of the graphics framerate. Perform some slight interpolation on the position of rendered objects and nobody can tell the difference

The original DayZ mod had an issue with this. If your framerate was lower your character would run slower. It's a very subtle effect, but when you ran several km alongside someone with a weaker computer they'd end up further back and you'd have to wait for them to catch up.

Render state usually isn't, but internal simulation and physics often updates using a fixed time step because it avoids many many problems caused by variable frame rates.

https://gafferongames.com/post/fix_your_timestep/