There's a mix of "very true" and "not so much" here. Good Greenfield solutions shouldn't ever pop into existence fully formed with all of the defects and tech debt that comes with that. You hit the nail on the head with the need for feedback loops and equal scrutiny should be given to ensure rapid feedback on Greenfield. We need to know as fast as possible how wrong we are about our value hypothesis and implementation. So, it's not small, incremental improvements. It's small experiments to validate the hypotheses (it's valuable, functional, stable, etc.) and rapid feedback to adjust. Deploy first.

"With software systems, as with any rehabilitation project, it is far less work to rebuild a new system than it is to perform CPR on the old one."

I've never seen this work for anything but trivial systems. When you try to re-write an existing system, you're always playing catchup. You not only need to try to re-create the capabilities of a system that's probably undocumented with tests ("business rules extraction" is a hilarious waste of money), but you also need to absorb the new capabilities as that system changes. They won't freeze those changes because that legacy system is running the business and the spice must flow. Using a disciplined strangler approach is much more likely to succeed. However, that's also not small, incremental improvements. That's evolving the old architecture to a new architecture in a way where we don't need to shut things down to get it done. However, it also requires rapid feedback and rapid feedback comes from small changes. Those things are tightly coupled.