I used the RT_PREEMPT patches in 2012/13, so my insight is most certainly rusty, dated and might even be wrong here or there. But still:
First of all, RT_PREEMPT is about realtime as in "hard realtime" for control systems. This has nothing to do with "small latency" (the cycle time could be minutes), but with deadline guarantees, allowing control loops over (realtime) network protocols, etc.
Then, almost all important additions of the RT_PREEMPT patches were mainlined one after the other. The last bits were never mainlined although essential for full preemptive kernel AFAIR, but:
Most "modern" (>15 years) OTS-platform (x86, x86-64) is increasingly unfit for realtime - no matter what kernel/OS you use, because your CPU is not in control. Beginning with DMA, later also "management engines", modern platforms might dethrone your CPU on the lowest ring entirely and for as long as they want, to serve a request/interrupt, e.g. fan control, while your CPU wakes up 500ms later realizing that it missed quite a few deadlines. (Fan control is a bad example, but DMA is not. Also Intel ME!) This makes almost all Linux PCs inherently unable to reliably keep these guarantees.
This puts the whole "hard realtime on Linux"-project in a pickle - since it requires full control over the platform. And most shops that go this route, will take the small additional step of using something well tested and with vendor support.
And the rest buys platform and OS with support from a trusted vendor.