Why not debate the points in the article on their own merits? Which parts do you agree or disagree with, and why?
And other than that point it’s just a badly written article. Yeah it’s fun to read and has swear words in it but Bob doesn’t actually back up any of his points with supporting arguments, the whole thing is just a polemic. And the reason for this lack of supporting arguments is that Bob doesn’t have any industry experience to draw on so he can’t provide any first hand accounts to support his opinion. It’s nothing but grand sweeping statements about an area he has zero familiarity with.
I think there's something like scaling laws for development teams. A number of things change, the cost of refactoring, the cost of communication, the need for communication, the plausibility of everyone knowing everything, etc.
Practices that are necessary for a large team can really hamstring a small team. When you're just a few people, you can cut corners larger organizations can not. If you really lean into that, you can kinda run circles around those larger organizations with just a few developers.
Technical debt is probably the biggest thing that changes with size. With a small team it's a tool you can use to get more done, a bit like a mortgage can let you do things you couldn't otherwise. Refactoring is cheap when you are few, so you can usually pay it off it gets too bad.
Technical debt in large project with many developers is very different, as large refactoring operations are prohibitively expensive, and you should go to great lengths to ensure it doesn't increase.