This is from 2018. It was extensively discussed at the time.

The broad consensus was that it was the .NET runtime's spin implementation at fault, both because of the suboptimal use of the PAUSE instruction itself and because of the overall design that had excessive spinning in a few spots. Effectively, IIRC, they were putting the "pause" instruction on the hot path where they needed to exit the loop synchronously, and that's just wrong. Basically no one sane would look at a change log that said "exit latency from pause will now be similar to a pipeline stall" and done anything but shrug.

It's since been addressed in .NET, as far as I know. And I'm not aware of any other affected code.