RT is all about privileging latency over throughput, whereas in HPC throughput is everything.
The term you want to search for is "OS jitter", lots of papers on that topic.
I'm not saying this is actually a sensible tradeoff for any extant HPC architecture, but it could be. You certainly want the 'OS' that runs the pipeline on your CPU to be real time!
It actually means "latency with a known upper bound". The point of it is to be able to give engineering guarantees - the actuators on the rocket engine vanes will move within N milliseconds of the input voltage from the gyroscope module changing; the robot arm motor will be de-energised within N milliseconds of the laser perimeter sensor activating.
Bounding the worst case can often mean making trade-offs in the best case, and that doesn't make sense in HPC because the hard upper bound just isn't necessary in this environment.
That said, why bother? Linux is customizable enough to strip out almost everything extraneous for nodes and has the largest pool of experienced developers, and it's unlikely that any of the other options would have any performance advantage - and less likely that they could keep any performance advantage once it was identified.