I agree many of the criticisms in other comments here, but the author does make at least one good point that I have not come across elsewhere, around whether and how to factor "accidental complexity" (which is mostly a proxy for tech debt here) into your velocity estimates.

> And conversely, if the team is picking overly complicated tech stacks, over-engineered designs, piling on tons of tech debt, and rubber-stamping all pull-requests, we should expect to see the velocity drop. And that will not happen if we score tasks based on their accidental complexity.

As much as we (as developers) may not like it, our performance is (sometimes) going to be measured, and it is often going to be done under the guise complexity points, and this part of the argument does seem at least like an improvement to the way it is sometimes conducted.