Nevermind, asked Fable and it did some tests:
The setup: RTX 5090 Laptop GPU, SVP's bundled stack (TensorRT 10.8, vstrt.dll) vs TensorRT-RTX 1.6.1 (vs-mlrt v16.2.test1 vstrt_rtx.dll), RIFE 4.26 Heavy, fp16 + static shape + CUDA graph + 2 streams (SVP defaults), synthetic source through vspipe, so the numbers are max interpolation throughput and source fps does not change them. Numbers below are TensorRT vs TensorRT-RTX, median of 5 runs per config; the dashed marks in the chart show what a 23.976 movie needs at each multiplier:

1080p (1920x1088): x2 132.6 vs 135.4, x3 102.8 vs 101.1, x4 91.2 vs 90.3, x5 84.7 vs 84.1. Identical within run to run noise.
4K (3840x2176): x2 30.6 vs 33.0, x3 22.6 vs 24.4, x4 20.3 vs 21.4, x5 19.4 vs 20.4. TensorRT-RTX is 5-8% faster and won every single repetition.
For a 23.976 movie that means 4.26 Heavy is real-time at 1080p up to x3 (x4 barely misses, 91 vs 96 needed) and not real-time at 4K even at x2.
Engine build for 4.26 Heavy: 99 to 112 seconds on TensorRT 10.8 vs 0.5 seconds on TensorRT-RTX (about 7 seconds total setup including first engine load). Rebuilt engines from scratch twice per backend to confirm, it holds.
Also confirmed the weird-size crash is really fixed in 1.6.1: 1920x832, 1280x768 and 896x512 all build and render fine.
So: same speed at 1080p, faster at 4K, and the 100 second engine build basically disappears. Looks like a clear win. SVP's script generator already has the rife_rtx hook that loads vstrt_rtx.dll, it just needs the updated rife package (vstrt_rtx.dll + tensorrt_rtx DLLs + newer vsmlrt.py).