Mainly because they're relatively simple graphically but they want to run at super high framerates, so the bottleneck is the CPU feeding the GPU each frame.
Which is basically memory bandwidth problem, which a large L3 cache helps a lot with. I've seen the same things with ClickHouse, having a larger L3 cache and fewer cpu cores can increase performance significantly.
Doesn't a lot of optimization target making your code and data more cache friendly because memory latency (not bandwidth?) kills performance absolutely (between other things like port usage I guess)?
If something is in L3 it is better for CPU "utilization" than stalling and reaching out to RAM. I guess there are eventually diminishing returns with too much cache, but...
I certainly don't care to do it, but running FPS above your frame rate can reduce latency if the frame buffering policy is reasonable (or you don't mind tearing). The difference isn't very big, especially if you're at 240Hz, but getting stuff to the display one frame sooner makes a difference.
But I've heard of triple buffering setups where you're displaying the current frame, and once you have a complete next frame, you can repeatedly render into the second next frame, but the next frame isn't swapped. In that case, it's hard to argue for any gain, since your next frame is way old when it's swapped to current.
Some rendering systems will do double buffering where the render is scheduled to start just in time to finish with a small margin before vBlank. If you've got that tuned just so, that's almost the same latency benefit as running unlocked, but if rendering takes too long you have a stutter.