That's not what real time, means though. Real time processing means taking signals as they come in, and outputting the transformed result such that there is as close to no signal lag as possible. The output can in fact be wildly lower or higher resolution, real-time does not particularly say anything about that. It's all about whether the output plays (for practical purposes) at the perceived "same time" as the input signal. There will always be some delay, but that delay can't get perceivable, and for obvious reasons there can't be any (significant) buffering.
Is that your private definition of "real-time"? I think it is common to define real-time processing by a specified, finite time between input and output. Many real-time processes are concerned more with the consistency of the latency than with its absolute value.
Latency is much more noticeable when you’re playing a musical instrument; 25-30ms is the point at which it becomes distracting in my (anecdotal) experience as a keyboardist. 50ms would be literally unplayable —- I cannot keep in time if latency is that severe. And that’s total output latency from the moment a key is depressed to the moment the sound comes out the speakers, so it’s important for every component in the signal chain to have the lowest possible latency. A bunch of 5-10ms delays adds up really quickly.
You can learn to play it. Pipe organs routinely have more than 50ms latency just from the distance the sound has to travel from the pipes to the organist. Add the time needed to set up steady oscillations in large pipes, and the slow pneumatic actions found in some organs, and >200ms latency is nothing unusual. The important thing is that the latency is consistent.
I think "rate" in the parent comment was just referring to speed, not sample rate. But yes, latency is critical for anything used during recording or performance. However way back when I used to make my own music I used non-realtime plugins sometimes and it was okay.