Another important point is you're measuring the default behavior of the various control systems. One can change that which would allow the user to observe something else.
And yep. You can even run a CPU at full clock all the time, meaning you will never observe a clock transition time. Cloud providers seem to do that.
I guess my point is the "clock frequency ramp time" is really due to the interplay of a bunch of different control systems, some in the OS and some not. And when those systems get mixed together, in a somewhat uncontrolled way (which is the case for most PCs), a huge amount of variability is the result and that's what the article did a good job quantifying but IMHO didn't make clear.
But at the time scales in your plots "how quickly CPUs change clock speeds" is basically an implementation choice.
Just my $0.02
I agree, there are multiple factors at play. But I don't think it's basically an implementation choice. Certainly it looks like it in some cases (S821 on battery, HSW-E and SNB-E). But it doesn't seem to be the case elsewhere. For example, speed shift lowers clock transition time by taking the OS out of the control loop.
I guess they must be trying to softly dis-incentivize really long chains, but not block them outright? It doesn't really make sense to me...