Some of what is being done is rather interesting;
Unfortunately, some operating systems adds stutters (even in VRR) that forces you to concurrently use an in-game cap and an RTSS cap. I've seen it de-stutter some games before. If stutter-reduction is numero uno priority over latency and other issues, multiple moats of caps can sometimes, indeed, be beneficial -- but it's tricky to tune.
If you must do an external frame rate cap with RetroArch internal framerate limiter -- then it is usually best to cap it slightly beyond
only as a fallback cap as a backup, e.g. RTSS 61fps or 62fps or 60.5fps cap.
You can try to tighten the fallback cap, but try to swing above, not below. Most emulators run at 59.94fps, so don't cap below 59.94. Use
www.testufo.com/refreshrate if you need a more precise refresh rate measurement. For certain emulator modules this helps smooths the frametime graph a smidge.
The only purpose of an external frame rate cap is as kind of a babysitter/cop on flawed internal framepacing of an emulator.
Ideally, for good framepacing and avoiding interference between capping algorithms -- the external cap should never activate before the internal cap. Meaning, the configured external cap should always be higher than the internal cap or internal throttle (e.g. simulated refresh rate of an emulator).
It's usually bad to use an external cap to throttle the average frame rate of RetroArch, because of its internal framepacing logic can have some nasty glitches when throttled by an external cap. 59.9 may usually work OK, but try 60 instead of 59.9 if your emulator modules are running at 59.94
Now, another method is to simply uncap RetroArch completely (so its cap logic doesn't glitch, and RTSS is completely in control of application framerate instead) and use RTSS Scanline Sync at 60Hz.
External capping works better if you let the emulator run at infinite frame rate (runs too fast), aka if you're running the emulator uncapped. This means if you turn off Scanline Sync, the emulator will run at scorching speeds (e.g. 2x to 5x+ too fast), so make sure you know what you're doing.
It's a game of pick-poisons, because I definitely sometimes (not always) get better results when utilizing an external cap (instead or simultaneous) -- but it has to be done in a way that doesn't cause the internal cap to glitch.
Sometimes tiered caps are used as layers of stutter protection during VRR -- but if you do this, try for progressively bigger for more-exterior.
- Lowest is internal-based throttle (e.g. in-game cap), then
- higher RTSS-based throttle (e.g. RTSS cap), then
- higher driver-based throttle (e.g. NVIDIA driver cap), then
- Higher monitor-based throttle (e.g. Monitor's max Hz whenever not using VSYNC OFF).
Caps further away from the game must be higher than the previous cap, to prevent cap-algorithm interference and/or race conditions that sometimes amplify stutters. Being that said, I wouldn't bother using too many moats (I never use RTSS and NVIDIA driver caps simultaneously).
TL;DR: You're simply using a backup cap as frametime-valley infill for a lower cap tier that accidentally creates a sharp frametime dip (e.g. frame is released a bit too early for whatever algorithmic reason).