I think you hit what the author was talking about, which is cranking out code so that it works (for whatever goal, in the case the author describes, user experience), not necessarily so that the code is good.
I learned Japanese, but when speaking it, I'm often hesitant. I used to hang out a lot with native speakers when I was younger, and there seems to be nothing middle-aged Japanese guys love more than seeing young men drink. After a few drinks, you stop second-guessing yourself, and so when speaking, words just came out, and my coworkers began laughing when, after I had spent all day stuttering and pausing, I would start spitting out fluid sentences. (A few more and I became unintelligible again, but for different reasons than hesitance; this was just as amusing to them.)
Coding is the same. Writing a small script, a prototype, or a little program for fun (or on the peak of the "Ballmer curve"), you don't think so much about structure and cleanliness, and you write the minimal amount that gets the job done, even if it's a hairy mess, and leave the editing pass for later (if ever). It's essentially the main tenet of Worse is Better camp and the Agile methodology: make it work as soon as you can.
I've worked at startups and large companies, and at both types of place, I've seen huge codebases, properly engineered and sometimes representing decades of man-hours, get scrapped before launch because they were wrong. I've also seen horrible code that ignored every good idea about building software that survived years. Personally, I have a bunch of code that is embarassing to look at, written as quick hacks, that has survived and done its job for years because it didn't try to understand the problem, just solve it.
Not that structure is bad or that engineering is wrong, but it seems to be independent of a program's survivability and its utility. In fact, Worse is Better seems to produce code that is more adaptable because its structure ignores edge cases that may turn out unimportant in the real world, so when unanticipated but important edge cases come up, the code is less rigid and can be adapted.
I think this lack of second guesses and of worrying about what doesn't matter for the problem at hand is exactly what the author is talking about. In terms of long-term maintenance, a prototype is cheap to build and easy to scrap; if it doesn't get scrapped and replaced, well...there will always be a project that junior programmers can cut their teeth on before subjecting a clean codebase to a kid fresh out of school.