"Realtime" does NOT mean low latency. It _CAN_ mean low latency, if that is what the user wants and the hardware is capable of delivering. What it really means is that latency is deterministic.
For audio applications what matters much more is that everything is predictable and you keep end to end latencies controllable. Imagine a concert pianist with a piano that will produce a sound randomly from instantaneous to quarter of a second to produce sounds when they press the keys. Some sounds may even come out of order. This is fine with TCP/IP, but Linux-based digital audio workstations with midi controllers and such that sort of performance would be unacceptable.
Linux under common configurations you will latencies vary by huge amounts. It is simply not capable of processing audio in a reliable enough manner that it can be suitable for audio production. You will see latencies randomly within a range of 10msec to 500 or a 1000 msecs depending on system loads. (probably 150-250msecs is very common) And system loads can change quite a bit... like double clicking on a fill to open a new MP3 sample, or aptd daemon kicking off and checking for security updates, or user alt-tab'ng between applications... Any disk activity is usually pretty damning.
What makes it worse for Linux (from a development perspective) is that high performance workloads often require a system with extremely lousy realtime performance. Think of server-style/database/batch workload. That way you take advantage of cache and all that happy stuff to make your processes go fast. Nice long, continuous reads from disk into memory, nice long lasting level3 caches to make your loops go fast, etc etc.
With a realtime-style workload you are going to be more then willing to flush those buffers and take page hits and all that stuff all over the place in exchange for the ability to say "X needs to get done every 10msec no matter what". So when Linux is configured for good realtime performance you will often see a dramatic loss in system efficiency if there is a realtime process actually running.
For audio work it's really important that you keep feeding the sound card and other devices audio data at a predictable rate. The hardware is effectively a "First In First Out" buffer that is always going to produce output regardless of whether or not you provide it information. Even if your system does not process the audio quick enough it is not going to stop your hardware from playing or recording audio information. As a result a system with poor realtime performance will create a large number of audio artifacts when loaded. You'll get echos, pops, squeeks, pauses, out of sync audio, out of sync video, stuttering video, scratches, etc etc and all other type of really bad things in your recordings and performances.