Architectural flexibility and architectural soundness are orthogonal properties. An inflexible system that is architecturally sound may obligate you to build more than its more flexible counterpart when novel use cases come around but it allows you to build more when these use cases come. An architecturally unsound system makes it prohibitively expensive to solve future use cases.

So the purpose of architecture, I'd say, is to first ensure soundness (which should cost no more than building an unsound system so long as you have the right skill set) and only then strike the right level of flexibility in the architecture (another, separate skill set that is valuable but less of a current industry problem, imo).

You can evolve the flexibility of a sound architecture but you can't do much with an unsound one. Inflexiblity in a system is generally a tractable "problem". Unsoundness is not (unwinding coupling, eg, is rarely tractable.)