please note that I dis say that there were cases where the system needed to reduce it's latencies.
but the fundamental problem is that no system is going to know that the priorities that you want for your audio processing are the righ priorities.
you say kill disk I/O and network I/O
what if you are using one of those for your audio? how is the system supposed to know?
it's a very different thing to say that the system should prioritize your audio over everything else than to say that the system shouldn't have 500ms pauses. the latter is something that everyone can agree to, the former is not.
linux has gotten much better since the early 2.6 days, and I don't think that anyone is saying that there isn't room for further improvement (they may not know where the problems are, but I don't see anyone arguing that there are definantly no problems)
but if you want to dedicate your box to audio processing, you should tell the system that you want to do so. it has no way of (accurately) knowing.
I am not saying that realtimekit is the right answer (I have no idea if it is or not, and am also not a fan of the idea that D-bus is being used for everything nowdays) but the idea that any desktop/server system should out-of-the-box be suitable for heavy audio processing is just wrong.
it should be good for _light_ audio processing (up to the squishy point where the load on the box causes enough contention for resources that you start having an unacceptable number of problems)