Developers want the default answer to "abandon the old mess and write a new one" (snarkiness fully on purpose); Joel's point is that the default answer ought to be incremental improvement. Not that it's always the right answer, but other answers ought to be scrutinized more closely than developers might like.
From a professional point of view, it's actually perfectly fair to consider that greenfielding a new project with hot new tech (or even "newer"-but-established tech, my personal favorite choice) is more fun than trudging through old code. Human factors matter a lot. But we are also professionally obligated not to overprivilege it.
Besides, if you treat it as a serious project instead of a series of hack jobs, in my experience, very serious incremental improvement still offers a lot of engineering challenge and fun. I think one of the biggest mistakes people make is to prejudge incremental improvements as a hack job, when it becomes a self-fulfilling prophecy.
Consider a COBOL codebase on a mainframe where you cannot find developers interested in learning the language and developing against the mainframe is convoluted -- you may not be able to pay talented people enough to toil in those coal mines, and you have to have to overpay subpar talent (or chase after the handful of expert mainframe COBOL developers.)
Eventually, everything will be on the new services, and you can shut down the legacy COBOL system and just keep the API gateway there to pretend. (If you can get clients switched over to consuming the new APIs directly, you can shut down the API gateway too—but good luck with that; their side probably has mainframes too.)
It also assumes that you have a proper API to start. It assumes that you have the organizational maturity to handle synchronizing two separate systems and the distributed transactions that entails.
The other problem not mentioned in the rewrite/refactor conversation is that the most common reason for rewrites is that the business has backed itself into a corner and the assumptions under the first system do not apply to where the business wants to go.
Well, to be honest, when we're talking about proper maintenance and advancement techniques, we must by definition be discussing the topic only for those with the discipline to correctly implement relevant techniques and policies. If your developers or management choose not to, be it for whatever reason up to and including total lack of requisite talent or experience somewhere, you've already lost and the only thing that can possibly save you is to address that problem first, and if that's not possible for whatever reason, you've simply already lost.
As a result, it turns out not to be an interesting case to discuss. Even if it is, probably, the dominant case in the field....
In some markets, the talent to handle this type of project doesn't exist. In other markets, the cost to acquire that talent is more than the marginal cost of rewriting the system.
Lost opportunity does suck. It would be nice if the first system was written in an extensible way with lots of tests and correct documentation, but it rarely is. All software needs to be replaced at some point. All software has a finite useful lifespan. So, this is a common problem. But you must have a responsible plan for replacing any first system. Any sort of project plan that has a magic day where the legacy system is shutdown and the second system is turned on is reckless and absurd. I've heard of failure rates for such projects being 80%, with the rest going way over budget before completion.
The best you can do when replacing a crufty old system is to employ strangulation. You slowly, methodically kill off the legacy system one feature at a time with the equivalent features in the well-written/tested new system. You run both systems side by side, sharing the processing load until one day, years in the future, when you have replaced all the features and the legacy system has nothing to do. It's a hassle and it requires everyone to be organized from start to finish, but you eliminate the big-bang release risks.
Luckily, with all the web services and factored out componentry we've been building in software over the past 10 years, the strangulation approach has never been more feasible.
There's lots of good youtube lectures and agile community blog posts on the topic of second systems and strategies to implement the strangulation. Here's an old classic that introduces the concept better than I could: