I had a Surface Book 2 that was particularly bad for this, I think because it uses the same connector as older versions, and it could not supply enough power. Undervolting seemed to help quite a bit.
Within that envelope, the CPU can boost up to its max turbo frequency when needed.
If there's an error in e.g. floating-point unit, it would just cause random errors in the output, but the game would probably keep running. That might be completely fine, if it's rare and you could undervolt just that unit a lot. Especially in somewhere in the graphics pipeline, where it would just generate visual noise. Also, I think energy consumed / heat is proportional to voltage squared, so it has a big effect.
The processor circuitry does not only consist of transistors dedicated to the datapath, a significant amount of transistors are used to control the datapath. If control transistors are faulty there is no guarantee about the processor behavior.
Also, I don't know about Intel cpu protections, but in modern secure hardware we include dedicated circuits for power/clock glitch detection. The glitch detection circuit is designed with a higher sensibility to power/clock fault than the rest of the circuit, this way its avoids that clock/power faults affect the integrity of the circuit output.
Not x86, but in college a series of courses used a battery powered embedded system with a Motorolla 68HC11. When the batteries ran low, conditional branches would never branch, which was very confusing. Everything else seemed to work fine though.
I'm just saying that linux does not do a great job of gracefully limiting CPU power to avoid a lower BIOS level limiter kicking in and performing worse than if it just throttled down a bit earlier.