Speeding it up provides benefit if speed was the bottleneck to begin with. As the author notes or hints at, faster code output leads to more features being delivered, more room for experimentation, etc. But that's not necessarily productivity, if the features offer no value, if the experiments end up on a shelf, if the maintenance burden and context becomes bigger than the organization can handle (even LLM-assisted).

I've done a lot of "rebuild" / "second system" projects and the recurring theme is that the new version does less than the original. I don't think that's entirely down to the reality of second systems, I think that's in part because software grows over time but developers / managers rarely remove functionality. A full rebuild allows product owners (usually different from the ones of the original software) to consider whether something is actually needed.