Absolutely, but even that idea of "modular design" would be something that needed to be discussed by the team - but this article would label this a "fixation". This distinction really isn't helpful. What IS helpful is knowing how much time to spend on such a debate, and when to set that stuff aside in service of moving on with the work.
I think this boils down to a roll of the dice. Its possible that some code is simple enough, or some engineer is smart enough, that tests are not really needed, but given the choice to not unit test would be made early, and its very hard to know the complexity of the solution at the beginning, you're really just rolling the dice with regards to whether it would work out. Sometimes you get a huge payout by delivering good code fast, but sometimes it can really blow up in your face with lots of prod errors.
Personally, I'd rather smooth out that large payout vs large explosion curve by just writing tests. If we could have pushed out the code faster, that is a loss, but if the code would have had many errors, thats a gain. So probability distribution with regards to payoffs is smoothed out.
I would say:
"Don't debate test coverage, code design, etc., unless they are relevant to meeting the customer's requirements."
Now, many times, these things are very relevant to meeting the requirements! Without tests, the odds of your code actually meeting the requirements is very low. Instead of finding and fixing problems with the code before it gets to customers, you get to fix it after you give it to customers and it fails, and you've probably just lost those customers.
To the "code design" point, I think that is covered in the "Models" section. Modeling the problem correctly leads very straightforwardly to getting the right design.
But I get what you say about doing those other things to make sure you don't run into the problem of changing requirements.
Part of the problem though is the varied skill level of developers and adequately timing the completion of these tasks. Most companies never budget appropriately for design and just expect banged out code. And there's not enough push back from developers on this, therefore it's become an expectation.
This feels like someone that just wants to throw whatever code they want over the wall without being bothered to design it well, write tests for it, and adhere to a team's shared design guidelines. I can't stand working with people like this. Just my two cents.
EDIT: I see that this isn't the primary point of the article, and that maybe the author means we could rid ourselves of so much debate by creating more powerful tools and working at a higher level of abstraction. I think that some of these same things are being attempted, though, when someone suggests a design pattern or something within existing code that could raise the level of abstraction, and that it's worthwhile to have that debate rather than label code design best practices as trivialities.