I'm sure this can be replicated in other ways but here is an example using Three.js and video seeking using a file with 100% I-Frames - https://jsfiddle.net/wxe5pk8c - You can switch between requestAnimationFrame, Three.js's setAnimationLoop (which uses rAF internally), and setInterval by setting animationStrategy to 1,2,3, respectively.
*Note* that as this JSFiddle uses iFrames, you'll need to click into the result iFrame to get Safari to avoid using its low power mode (meant for ads) which limits rendering to 30fps.
Below are average framerates from various devices I have tested:
1st Gen iPad Pro
2011 Macbook Pro
2019 Macbook Pro
Also, note that this JSFiddle example is susceptible to this issue - https://bugs.webkit.org/show_bug.cgi?id=211295 but I believe it should still be a valid test for comparison between requestAnimationFrame and setInterval / setTimeout performance testing.
Quick update - This can be replicated on many of the Three.js examples (not just the somewhat esoteric video seeking example above). Try https://threejs.org/examples/#webgl_interactive_cubes_gpu and switch from requestAnimationFrame to setInterval - I see around a 10-15fps difference on both my iPad Pro and older Macbook Pro.
And a potentially unrelated but interesting behavior - On the above video seeking JSFiddle, when tested on an iOS device, sometimes the textures stop updating for a small period of time (independent from rendered rAF FPS) but can somehow be *fixed* immediately by touching the screen. I doubt that's directly related to the core rAF performance differences with setInterval, but I figured I'd mention it in case it helps diagnose things.
Regarding the issue noted in my most recent comment, I opened a new issue specifically about video-based textures not updating - https://bugs.webkit.org/show_bug.cgi?id=211750