I think that Agile development draws upon experiences and techniques that have been proven to work. You mentioned JAD in your post, and I coincidently made an observation that JAD is one method proven to reduce scope creep in my latest post about reducing risk.

Agile development has been getting a lot of press and attention at the expense of traditional, waterfall-oriented projects, but I think that it is worth examining what we should expect, what is working, and what needs to be re-thought and/or discarded, regardless of the methodology. Determining what to use and when can be based on circumstances, for example. Most business-oriented software tends to need adaptability, and I’m sure other applications like medical devices (I have no experience in this field) need to very crisp and stable requirements that are rigorously tested against the spec.

There is no expectation that anything is ‘wrong’, but a realisation that change is inevitable, and rather than spend huge amounts of time trying to plan, accommodate and mitigate the risk of these changes at the start of the project, usually by way of a long protracted requirements analysis phase which is ‘wrong’ as soon as it’s completed. Agile allows for that change and removes the dependencies on individual deliverables (as much as possible) thus limiting risk.
True there is a need for trust, as there is a more formal PM methodology such as Prince2; however, unlike prince there is no dependency on documents, and more on mutual communication. It is a much more open and pleasurable environment to work in and whilst it may not fir all circumstances, has, in my experience produced much more resilient and robust software than other methods of ‘control’

This whole article is based on a shallow understanding of Agile. Apparently you have not really used Agile in real world, you just heard about it.