Right, but I was saying that the "biggest benefit" of waterfall was never actually one to begin with -- Agile was built around the assumption that requirements will constantly change because that's what happens in the real world. If requirements accuracy is the most important thing in your project, you deal with the change management implications. Otherwise, you go Agile and accept that you may not be able to guarantee a specific feature by a specific date/release.

It's a two way street though: the business folks need to understand that they're giving up some control and predictability in exchange for lower overhead and faster delivery. This is the hardest part of Agile IMO since most business / product folks don't like not being in control. Agile gives engineering more autonomy, but only if the business respects that autonomy. If the business starts dictating too many processes/priorities, the whole thing crumbles into a waterfall mess (even if you call it "Agile").