Vanquish may be coming to PC!

There are two main strategies for simulating time in game engines.

The first is to assume a fixed time step from frame to frame, and attempt to ensure that the game runs at a frame rate that matches that fixed time step. For example, you might say in a game designed to run at 30fps that each frame moved the simulation forward 33ms. If your simulation takes fewer than 33ms to update, you delay presenting it until the right time - this is effectively capping the framerate. If you take more than 33ms, the game will appear to run in slow-motion.

This kind of system has two major advantages - first, the code is much simpler because many assumptions can be made based on the fact that time steps are fixed. Especially because Physics is so time dependent, and because you are essentially trying to model continuous physical processes in discrete chunks, it's a lot easier to make decisions about how things should resolve when time is not an additional variable to every system. The other main advantage is that the code can use those assumptions of a fixed dT to simplify calculations, and so can run faster in some cases. That's pretty marginal though.

The other major approach is to set the time step to some multiple of real world time, and to engineer every system to handle any random time interval being thrown at it. The advantage here is that there is no upper limit on framerate, so you can present frames as fast as you like without the game appearing to run in fast-motion. The disadvantage is that every time-dependent function in the code needs to be able to handle any random value of deltaT, which exposes a lot of potential edge cases. There are a LOT of potential edge case bugs that appear in variable timestep games running at extremely low or high frame rates.

In cases like this, the problem is that these games are using a variable time step, but some function in the game is not properly handling a variable dT in some way. on Console, even though a game engine supports variable time step on PC, Devs will try to stick hard to their target framerate on the low end (optimizing and reducing the amount of work in cases of low framerate) and cap the framerate on the high end to avoid wild swings in framerate. Then, often because the developers have assumed the vast majority of players are on consoles, and because consoles have stricter failure points in terms of physical memory than PCs, most testing was done on consoles, so the functions that handle edge cases of dT wrong were not found to be faulty. Additionally, because many fundamental engineering choices change when dT is fixed vs. variable, these problems can be excessively costly to fix, especially if they hit what is perceived to be a smaller audience.

And while people may be talking about multi threading here, it's unlikely that game-effecting physics processes are being run concurrently to the main thread in the cases you are talking about - when systems like AI, collision, etc. are all dependent on the output of physics, there's not really a lot of ability to offload the entire physics simulation to another thread. For things like particle systems, some ragdolls, debris etc. it's possible, however.