Let's consider an agile software project.
In the beginning of a project each Story can be implemented quite quickly because the code base is small, there're few dependecies between different parts of code, we don't have to maintain backward compatibility etc.
But as the team moves forward the code base becomes larger, more complex - it requires more time to understand all the dependecies. We need to spend more time talking to other developers about the current architecture. A Story that used to be done during a few days, now becomes to require at lest a week.
Nearer to the end of the project fixing even a minor bug often becomes very difficult because the code base is huge, there are a lot of dependecies and restrictions (for example, backward compatibility).
So as the team progresses its velocity should slow down. The same Story in the beginning of the project may be estimated as 1 Story Point, but the this very Story taken into development at the end of the project may be estimated by the team as 10 Story Points or greater.
Agile manifest sates that an agile team should maintain a constant pace - is it really possible?
The team, of course, may begin to give more points to Stories to compensate for this complexity increasing, but that would mean that Story Point itself isn't a fixed unit of measure, and threrefore we can't use Story Points for forecasting the amount of time required to complete the project.