The relationship between requirements stability and up-front planning

Is there a relationship between how stable a system's requirements are and how much up-front planning teams do?

If agile means delaying architectural effort till the last sensible moment so you can better respond to change and have less rework, then perhaps we can assume that the more stable your requirements are the more up-front planning you can do, so you can get the benefits of an complete architecture design that has been better thought through.

But is this the case?

It doesn't seem to be. A highly agile team will still try to minimise its up-front effort, defining requirements later and making architectural decisions as close as possible to the time that they're needed. Even when they have fairly stable requirements, such as when doing a functional migration.

This isn't because teams are looking for an excuse to avoid up-front effort, but rather it allows them to focus on the high-value functionality rather than get bogged down in the detail and minutiae of defining a complete set of requirements at the beginning and losing sight of the big picture.

And anyway, even if we have fairly stable requirements, who knows exactly what's going to change in advance, and hence what can be left till later?