Throwing away an established code base is a completely different thing from throwing away a few-days-old prototype, and not what the article is suggesting. The points you mention don't apply to the prototype case.
This is such a HN phenomenon it infuriates me. Read article. Then read comment that misconstrues article to be something completely different, accompanied with loud critique. Read replies all in violent agreement to obviously self-evident strawman.
The misunderstanding you have is that often the article isn't the point. Just like a football match in a pub isn't always the point. People just want to chime in - the comment section is like an ephemeral pub.
If that bugs you because you consume information on the web rather than socialize, the solution is simple: don't read comment sections and make up your own mind about the article.
I feel this. What I do now is increase the points of the PoC (real estimated PoC time + optimization).
I get the PoC down asap then as soon as it’s proven (privately to myself) I move onto optimizing. If it fails then I communicate early to discuss a change of scope.
Assuming it succeeds, by the time I present it I have already done significant work making it production ready. So to request an extra 10-25% time to “smooth out the edges” goes over easy after the demo.
In reality I end up with 50-75% time to get it prod ready. The rest is QA + prod bug fixes to take it over the (practically scoped) finish line.