There are still organizations that claim they do not use an iterative development process. Why is that? Wasn't this argument settled long ago?

The so-called non-iterative methods, such as waterfall, are most often used in organizations where the dominating culture is that of Mistake-Avoidance. This can come from a number of sources: don't waste the taxpayer's money, we can't tell the business people we made a mistake, or simply management that has never developed software using modern IDE's.

Non-iterative methods are used even in organizations that do not manage by fear. In talking to the IT department of a southeast asian central bank, I discovered they were happy and well adjusted, but insisted they did not use iteration. Projects lasted between 9 to 36 months. Delving deeper, it turned out that, yes, once fielded they did get feedback from users of changes, fixes, and enhancements, and yes, they collected those over a period of 6 or so months, at which point they would often start a new version of the application. My claim was that their iterations were just very, very, long.

Short iterations (e.g., daily) are empowered by modern IDE's. Iterative developement is essential for delivery of effective software. Management's avoidance of iteration centers around a fear of chaos and loss of control. "How do you know you are done?", "How do you budget and staff the project?", etc.

The analogy I like to use is that of the Sailboat and the Locomotive. Iterative development is captaining a sailboat---a method designed to handle changes in wind direction, currents, crew, revised destination, etc. Non-iterative development is a locomotive, meant to be predictable and repeatable. It is possible that in a restricted domain and problem space that software development could be organized to run like a train schedule. Beware if there is ever a bridge out, though.

Software professionals need to think, plan, act and manage more as sailors than conductors.