Not sure, but there might be a misunderstanding here:

The value of your bug fix is cashed out only when it reaches the customer, not when you have finished implementing it.

There is a cost of delay for value to reach the customer, and we want that delay to be as short as possible.

So it doesn't matter if you fix 10 bugs because your 10th bug is going to reach production 5x10 hours (that's an exageration, but you get the point) after you had fixed it (which is why the article mentions latency and not touch time)

You can tell me "yes but I also participate in the code review effort in parallel). Yes, but then you are not fixing 10 bugs, you are fixing less and reviewing more, and reviews take longer than implementation (especially with LLMs now in the loop).

It's because of the pretty counter-intuitive Little's Law : the more in-progress you have in parallel, the slower it will get for each item to be completed.