Your argument seems to support the claim that "bad things have been done in the name of maintainability"

Hm. I don't think I wrote what you read. The gist of my post is that the simpler the code, the more maintainable it is.

I get nervous when I see people suggesting that the initial design and implementation has to be done so as to accommodate future possibilities:

Unless it is allowed for in the initial design and implementation you will pay far more to "retro-fit" maintainability

The initial design (spec) should describe the actual, present day requirements. Nothing more.

The initial implementation should implement that design and nothing more. No what-ifs, wouldn't-it-be-nice-ifs, or maybes. And absolutely no we-coulds.

Anything beyond those actual requirements is an upfront cost that may never show return.

It adds time to schedules--have you ever had one that wasn't too tight?

It adds cost to the budget--have you ever had one that had a surplus?

Complex code is always harder to maintain, no matter how well written it is. And writing complex code well always takes considerably longer and costs more.

Think of it this way.

If we could predict all future requirements and implement them perfectly up front, then maintenance would never be necessary. But it never works out that way.

And the moment you accept that the original assessment of requirements will be shown to be wrong once the code goes live; that even when the requirements are correct, that bugs will make it into production; and that new (unimagined and unimaginable) requirements will always arise; the sooner it becomes clear that the earlier and more cheaply and more simply you get your first cut into real-world use, the sooner you will find out what bugs need correcting, and what changes arise, and the more likely it is that you'll be given a budget to achieve them. And the easier they will be to achieve.

If you think now that one day you might need X; and you implement X, and later you do need X, then you've saved some maintenance budget down the road. But you've added to the costs at the time when they are most critical, when developing a new and unproven piece of code.

Guess wrong; implement the wrong thing; and it is pure cost at both ends.

I prioritise this way:

1. Make it work.

   Self-explanatory.

2. Do so on time & budget.

   If you overrun either, you may never make it into production. And if you do, you will be under severe scrutiny when you go looking for a maintenance budget.

3. Make it work in a timely fashion.

   If your target response time is 3 seconds and you take 10. You've lost half your customers.

   If you delivery Friday's results on Sunday, you're too late.

   ...

4. Make the codebase clean, flexible, reusable, and maintainable.

   These are aspirations, not requirements.