If you don't like the unit "completions per hour", consider that you don't have to drive for an hour or even go a mile to go 60 miles per hour.
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.
I hate it a little less now :)
Hence, "it's 10x faster" is a valid way to write "it does the same work in 1/10 the time".
I still think "X times less than" can GTFO though - as in 10,000 is "seven times less than" 70,000 - which is the kind of thing I'm seeing more recently. That wasn't mentioned in the article though, it was maybe a bit unfair to lump them together.
Seconds of developer time could be saved every day!