It's not as effective if you're not working in software, or at least I don't know how effective it is, but that's not what this submission is about.
"Don't assume that your team should build what it's told to build. Instead assume the opposite: nobody really knows what you should build, not even the people asking for it. Your team's job is to take those ideas, test them, and learn what you should really build." [0]
That's your team's job. Not to make guesses by assuming you know what's best, not to do what they're told by customers, but to run tests and use results to inform next steps. That's the entire purpose of a development team, and you simply cannot do this without a quick iterative cycle.
[0] The Art of Agile Development, pp. 453
I think the reason people aren't fully agreeing with you is that there's a lot of important stuff where a quick iterative cycle in front of a customer eliminates the possibility of high-value outcomes.
The point you're trying to make isn't the novel insight I think you're trying to present it as. Of course you don't just build what your customer asks for blindly, of course you design with the future in mind, none of that is precluded whatsoever by iterating quickly to provide value and test what your customer needs.
In a past life I had developed 3 generations of tooling to support a certain complex and information-dense task that was essential to the business. Generational change was not incremental and required months/years exploring the problem domain and prototyping and backtracking and intentionally not consulting anyone. If I came out of stealth too early I'd be directed back to a gen 1 approach that was functionally and architecturally exhausted and could not meet the business needs at a reasonable cost. By the time I was done I understood the problem domain better than the business did. (I will stipulate that most of the time this is a bad approach--but sometimes it's absolutely necessary.)
My (aspirational) purpose at work is to surprise my customer with valuable and insightful solutions that they could not have arrived at incrementally, or with their methods, or with their team. Surely you can see how this is in direct conflict with rapid iteration in collaboration with them?
Except you're not inventing things, you're discovering things. That's a big difference. The best way to discover if something works, is to put it into the hands of customers as fast as possible while minimizing your expense at doing so.
You're "lowercase a" agile if you operate under the prioritization outlined in the Agile Manifesto. I think most of the people who've found consistent success with agile would say that's what matters is more about that than about XP or SCRUM or Kanban or whatever.
Those systems can help, but to be agile is to focus more on individuals, working software, customer collaboration, and responsiveness and less on processes, documentation, contracts, and plans.
I hesitate even to reword the items in the manifesto, just because I know it took a lot of very smart people a good while to agree to the specific wording, and it's seemingly stood the test of time.