[emn13]

You are of course completely correct. However, I do think numbers like these are more intuitive when people talk about duration (or latency, or time taken; depending on context) rather than speed outside of very narrow situations.

In a car, 60mph has some kind of well-known interpretation; there's an experience to that that people can at least vaguely identify. And it's also related to fairly intrinsic limits, such as legal speed limits, safety, etc.

But even in a car, people tend to care about trip-times, not speeds. And speeds are harder to work with; If you travel 30mph on your commute to work due to traffic; and 60mph on your way home - what was your average speed? Not 45.

Outside of a car and in a computation context, it's even more impractical to talk about "speed" - after all, we're usually dealing with lots of stages; and it's rather easier to simply add up latencies than it is to some reciprocal of reciprocals dance. Even if time is workload dependent, then the time-per-workload framing tends to be more helpful than the workload-per-time framing.

As a corollary, people currently talk about high refresh gaming, and will happily report how some workload went from 300fps to 400fps, without noting that this is the same frametime reduction as going from 48 to 50fps (setting aside perceptual limitations). Workload-per-time is pretty unintuitive.