Ben: There are a lot of advantages of waterfall. Here are some:
I'm going to gently disagree that the following are generally true :)
* Many kinds of software (eg shrinkwrap) have very large deployment costs. That makes iterative development not really an option.
Iterative development can still happen within a larger release deployment cycle. Just because its shrinkwrap, doesn't mean it needs to be waterfall.
* 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.
Fixed bid has the effect of inflated prices (the contracter is protecting his risk) and inflated requirements (because the customer is doing the same). It generally guarantees that both parties lose (late software for the client, penalty payments for the contractor) when the waterfall estimate is wrong (and you know it always is).
* If you know what you want to develop, it is generally cheaper to develop it with a waterfall methodology.
If you know what you want, and you have absoluting critical needs of getting exactly what you want (generally high risk software, e.g. the space shuttle), then waterfall might get you there, but I doubt it will ever be cheaper.
I'm not saything there isn't a place for waterfall, but the above reasons alone are not sufficient in my view to prefer waterfall over an agile approach.