Notes:
Change happens. Changes has been dealt with in most of the projects I've ever been involved with. (A notable exception being one where the customer made himself totally unavailable after project initiation – and expected the development team to divine the detailed requirements and manage trade-offs without his involvement. After delivery, there were a lot of change requests.)
Regardless of the process model dealing with change is a matter of understanding the business benefits and development costs – and the cost of quantifying these.
The difference I see between the way I've always done this and the Agile methods I've looked into is that I've costed changes either as an additional charge or to be absorbed into the project budget, while Agile assumes that they come from a fixed project iteration budget. (And that, implicitly, something unimportant will be dropped from the project iteration.)