In general, I think the author's cynicism about productivity research is justified, but I think it could have been directed more productively. (NB: the following comments say nothing about areas of software engineering research outside of productivity.)
Commercial software engineering is a creative endeavor; it is not a science, nor is it a manufacturing process. It does not have natural, universal laws. What makes a team 'productive' varies massively based on constraints imposed by business model, product, customer expectations, leadership values, and of course the individuals of which it consists.
I do not believe in the possibility of a "General Theory of Productivity." I'm highly skeptical of attempts to quantify the precise relationship between error discovery stage and cost in a way that is generalizable, although I think it might be possible given a large group of engineers using a highly homogenous process, tools, and accounting. Google is pretty close to this (common dev infrastructure across tens of thousands of engineers), and even across Google this kind of generalization would be extremely difficult.
There is no universal physics of software engineering. As a result, academic research into productivity can be difficult to generalize (which is why, I think, you often see researchers twisting themselves into knots). Instead, my rec is to focus on a few key metrics that are aligned with your business' or team's goals (search for DORA for a good starting set) and to reflect often on what you feel makes your team work well and what doesn't.