Interesting blog post, but I'm unconvinced.
First, there's no such thing as something you should "never" do, especially when it comes to code. Our problems are so abstract that few if any tools should be off-limits.
Second, the author leaves out any examples of where rewrites succeeded. Windows NT was effectively a rewrite and is the grandfather of every version of Windows that came after Windows ME. Game engines and websites are rewritten all the time to varying degrees of success. OBS was a full rewrite and they're killing it. Slack did a rewrite and, whether you like them or not, they've been very successful.
Some of what he says makes no sense IMO, like:
> [...] when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.
Perhaps there's no reason to believe that you will certainly do a better job, but surely much of the time there are lessons to be learned even if the old team is entirely gone. When I'm brought on to new projects, I can pretty quickly tell what's dysfunctional, why that is, and what parts can at least benefit from serious cleanup.
He goes on:
> [...] you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.
What the author is doing here is making the same logical fallacy that he attempted to point out in the opposite position, except he's actually making it here. He's assuming that the team rewriting a hypothetical codebase are going to make most of the same old mistakes again. While that's definitely possible, is it really so certain? Can no one learn lessons from code regardless of whether they themselves wrote it?
A full rewrite was a bad idea for Netscape at a time where the market around the web was brand new and moving ridiculously fast. It's the circumstances that lead to the Netscape rewrite being a disaster. Not all software is subject to those issues, commercial or not, and not all software teams are the same.