Maybe it's the whole "let's run Linux on it because we can" phenomenon. The microcontrollers in the old electronic radios didn't run an OS but interacted with the hardware directly. The number of instructions executed from sensing the dial change to updating the tuner and display would probably be less than 100. Now it's half a dozen layers of abstraction and millions of instructions to do the same thing, on a processor which is maybe "only" 1000x faster at most...
In that setting, nobody's going to say, "Hey, let's just pop this radio into our cars, live with it for a few weeks, and then figure out where we need to go next." It's too late. Instead I think the thing to do is force convergence early and often in the product timeline, so that the supposedly-little things like this have plenty of time to get noticed and fixed.
A good example of this is Apple. I'm told that in consumer electronics the typical number of iterations with physical prototypes is 3-7. For the first iPod, Apple went through more than 100. The difference was enough for them to crush the competition so thoroughly that people these days are surprised to hear that there were MP3 players before the iPod (and smartphones before the iPhone).
...which is actually quite suitable for the safety-critical parts of a car like the ECU and other controllers that control the actual driving aspect, but not for everything else that doesn't need such a level of process.
On the other hand, I suppose it could also be blamed on the lack of "performance is a feature" --- if they specified the radio to be as responsive as the accelerator and brake, for example.
I do think short-cycle methods have some intrinsic advantages, though. By making critical functionality available much earlier for testing, you get more time and more chances to make sure it's really safe. If early versions are bad, you get early warning signs that aren't available in a Waterfall process. And if testing turns up issues early on, it's much cheaper to make fundamental architectural changes: less code to change and more time to change it in. And Waterfall processes aren't at good at dealing with unknown unknowns; some things you only learn by trying them out.
Another source of delay is just the length of audio packets themselves (have to wait for the beginning of one) and radio limitations.
Or am I totally misreading this?
Coupled with a decoder that can manage double the actual frame rate, it should cut the switch time with something like on average 1/4, worst case better than 1/2.
But they're compressed in such a way that doesn't require any previous frame. It's compressed like a picture would be.