Moving in this direction is making the problem much harder to solve. Its usually counterproductive to make instinctive changes to a system because they "ought to make it better". I've found its preferable to have the system generate a figure of merit- how well its performing- and then seek optimizations to improve it.
A 5k control loop would be difficult on some of our realtime systems mostly due to lack of cpu headroom but estimating based on cpu utilization we could hit it with a cpu upgrade; these systems move a lot of data which is a different problem than controlling I/O signals. In comparison we do have a 5k control loop system running I/O lines on a 32 bit 120mhz PPC which runs full-up at about 95% utilization; right on the ragged edge- thats a vxWorks system. Probably would be no problem in Linux on a 64 bit modern CPU.
As to single-user mode, the problem is not so much other tasks but selecting priorities and scheduling algorithms for the tasks that need to run realtime vs letting the others run at default priority. That is much easier to do with the system running full-up. We don't find readily measurable disturbances in realtime scheduling even when we have users coming in via remote desktop and running the gui control software- all that runs at default priority after the hard realtime processes execute.
On some of the fancy network I/O systems we do apply cpu affinity to some threads provided a measured increase of scheduling stability in some cases. But even those cases were out at the ragged edge in our stress-test system.
The Linux scheduler is really quite good, but application software architecture is probably the most important factor. Its very easy to have design assumptions serialize ops which could be parallel or inadvertently incorporate blocking/high-overhead calls in the critical realtime code- once you do that a fancy scheduler isn't going to help.
Those are all good real world observations. Sometimes people do ask theoretical questions though, so it's good to give them options they're comfortable with.