- Many kinds of software (eg shrinkwrap) have very large deployment costs. That makes iterative development not really an option.
- Waterfall makes sense if you are contracting out a project on a fixed bid price. To protect the two sides the contract has to specify what will be built before anything is built to such an extent that you're basically going to be doing waterfall anyways.
- If you know what you want to develop, it is generally cheaper to develop it with a waterfall methodology.
In short, iterative development methodologies are not a pancea. They deserve a (fairly large) place in software development, but are not always appropriate.
In any case I think you misunderstand the progression at this company. The company always used a waterfall methodology. However until a few years ago they weren't very strict about it, people would realize that they wanted tweaks to specs, would informally communicate them, and would generally be accomodated. However the phenomena of mutating specs came to be seen as a problem, and so a corporate policy came down of having a strict waterfall - in order to change a spec you absolutely had to have a formal change request which had to get formally reviewed, etc.
In other words it wasn't mandating the waterfall methodology from scratch. It was a PHB saying, "Change requests are a problem, we have to limit them." And then limiting them by forcing them to go through bureaucracy.
However once that was done it was certainly easier to make the second PHB choice of offshoring...
Cheers,
Ben