A requirement changing mid-project is routinely framed as somebody's mistake — the business did not know what it wanted, or the analyst did not ask properly. Occasionally that is true. Far more often the change is a rational update to new information, and the real failure is a plan that treated the original understanding as final.
The best information arrives late
Nobody knows less about a system than at the moment of specifying it. Understanding improves as things get built, used, and tested — which means the most accurate requirements necessarily appear after the point at which the plan wanted them fixed.
A process that forbids late change is optimising to preserve an early, less-informed decision.
Sequence for reversibility
Some decisions are cheap to revisit; others harden everything downstream. Data models, identity, and integration contracts are expensive to change later. Screen layouts and business rules usually are not.
Defer the reversible decisions and take the irreversible ones deliberately, with the most evidence you can gather first. Most schedule damage comes from getting that ordering backwards.
Price change in displacement, not hours
The question "how long will this take?" is less useful than "what does this push out?". Expressed as a trade, a change request becomes a decision the business can actually make.
It also removes the fiction that scope can grow without consequence provided everyone works a little harder.
Keep the batch small
Short cycles limit how much work a change can invalidate. If direction is confirmed every two weeks, a wrong assumption costs two weeks. If it is confirmed at the end, it can cost the project.
This is the practical argument for iteration, and it holds regardless of which methodology it is dressed in.
The objective is not a plan that never changes. It is a plan whose cost of changing stays roughly flat over time.