Software development has the advantage of happening in an environment where the cost of failure is relatively low. A bad change might be caught by the test suite before it ever sees production. If it does get to production, there might be consequences, but not the kind that typically kills people.

In fact, I think software engineering in general should lean into this idea on most things. Don’t try to ignore failure, but catch failure as fast as possible. Things like medical devices and aeronautic software should continue using formal verification methods, but the rest of us should iterate fast.

Iterating fast doesn’t work for other things. I’m a programmer by trade, but I have enough electrical knowledge that I once took up a contract for designing a PCB. I tried to do the “one thing at a time” approach, and it just doesn’t work very well there. Non-trivial PCBs will have errors in them the first few times you try them, and you’ll need to go back for a redesign. In software, that potentially takes minutes or even seconds. But in PCBs, you have to order out to a company to make them and wait at least a week for them to turn it around. Even if you have equipment to do it yourself, it still takes hours. You just have to batch up your changes. (Electrical simulators can potentially help with this, though.)

In government, the effects of policy could take years or even decades to work out. Single change at a time would be a stranglehold on the ability to fix problems.