I have previously run Linux as a desktop, with an RT kernel. It was interesting to see the effect.
You're right, in that in some ways the "performance" did feel slower, but of course the reason why is that user facing tasks (e.g. scroll that window) would get less of a look-in on CPU time than something else running at a higher priority but has no obvious visible consequences.
What's interesting is to see the impact of a real time OS on single-purpose GUI systems, specifically car infotainment systems. I'm not sure about now, but certainly only a very few years ago the systems that were praised for being smooth, glitch free graphics were the ones based on QNX. If the GUI is the most important task in the process list, it's never going to glitch. I suspect that Linux / Android based systems are catching up, mostly likely through a preponderance of CPU / GPU performance...
BlackBerry did / still do an excellent job with QNX and its graphics libraries for slick, touch-enabled applications. All of this was in BB10 OS for their smartphones, which were slick to use but sadly bereft of application support. Not the first time history is littered with the dead corpse of something technologically superior, but unwanted...
I have done GUIs using X servers running on VxWorks (perhaps the hardest of bastard-hard-real-time OSes). Real time X is, well, entertaining! Actually, this was rather good. The pipe connection between application core and graphics meant that the core wasn't left hanging around for some graphics engine to get on with it; the pipe acts as a buffer. Not quite so easy with other ways of doing graphics.
I have seen other examples of real time GUIs. The terminals used in Japan Rail ticket offices are a custom design; a combination of buttons and a nice touch screen, keyboard for in-case.
You have to go into one of these offices and set them a challenge (like, sell you a ticket for the train that's arriving at that very moment and will depart in the next 30 seconds). I'm pretty sure that the staff are trained specifically in the use of these terminals and have to sit speed test. What I've noticed is that, to process your booking request, it involves a combination of button presses, and presses on soft-buttons that are shown on the touch screen. The soft buttons on the touch screen will vary depending on the nature of your booking. And, if harried for time, these people are really, really fast.
What's interesting is that, to support such rapid use of the terminal to make a booking, the software generating the display for the soft buttons that are appearing on the screen has to do it fast enough, because when their thumb is heading downwards towards a soft button they know is going to be there, the button has got to be "ready" to press otherwise it's going to all go wrong. By my reckoning, watching an expert book a complex 3-train journey with reserved seating in a matter of seconds, there are astonishingly few 10s of milliseconds for the database query to be generated, submitted, processed, results returned, display geneated, soft button "created" ready to be pressed, and doing this a lot during the entire booking procedure. And, this is happening nationwide, all day, seemingly without fail.
The whole combination of staff training, terminal design, network infrastructure, database back end being fast enough to work that quickly disguises a very, very deep truth about selling train tickets. If you can sell them quicker, you can sell more of them. And, so far as I can see, betrayed by the reality of the technology they must have in place to make happen what you can see happen with your own eyes, JR has taken that very great extremes; they really get it, and have invested heavily in it.
So, whenever I have the souless experience of buying a train ticket here in the UK; well, it's enough to make one weep, even before they announce the cancellation of your service just after you've paid for it.