To defend the idea, I think it starts with the assumption that software is often a moving target so "correctness" is at best a temporary state. If you had to use a codebase at any point of time you would obviously want the correct one, but if you look at the lifespan of software it would be better to have the simpler code. Simpler is (usually) easier to fix, easier to extend and easier to learn.
I think the author made this a little inflammatory to get people to think about it in these terms.
Easier to fix, yes. Tends to get more complex in nasty and ugly ways.
Easier to extend, almost never. Proper design for extensibility has an extra bit of complexity over the most obvious.
Simplistic implementations tend to be tossed away and are good for unscalable prototypes.
Easier to learn, definitely not. The simplest code comes from deep understanding of problem domain and algorithms. It is almost exactly like with writing brevity while not losing the point.
It is easy to end up with simplistic instead of simple.
There is that famous quote by Dijkstra which I'd rather not butcher from memory.
I think the author made this a little inflammatory to get people to think about it in these terms.