The task being spelled-out here is also pretty much one program being done by one person who is more-or-less fitting it together by feel.

What utter rubbish. The top level "program" might be might be a single standalone application. Or it might be the home page of a new website. Or the first subpage in a sub-application. Whatever the form of the application, there is a top level, that structured programming suggests, is itself relatively simple, but which dictates considerable influence over the structure and interfaces of the next level of components.

Once that level has been laid out, excercised, demonstrated and approved--usually a matter of hours or days--a team of any size required can start working on the internals of the next layer deeper, as their interfaces with the top level have been defined. And the documentation people can start documenting the top level straight away, in parallel. This isolation of concerns reduces coupling (the Holy Grail), between the lower levels and allows the teams to operate free from co-dependancies upon each other.

The process works just as well for a team of 720 people as it does for one, because the interfaces between each subgroup are clearly defined. Even when those interfaces need to change, whether through customer requirements altering from above, or implementation requirements from below, the changes and negotiations they require are isolated to one vertical path through the development, not scattered throughout the project. Meetings are smaller, decisions are quicker, parallel paths continue unaffected.

The hierachal breakdown of projects into sub-projects falls out naturally from the design process, rather than being artificially imposed from on-high by capricious whim. At the end of each day, each sub-project has a working program. The top level works, because each of it's dependants are mocked up. Each of the sub-groups substitute their part for its mockup in a copy, and can develop and test independant of each other.

Only once they are happy with their testing does their part get integrated back into the top level. And if it breaks, the top level reverts to using the mockup, allowing it to continue to test other interfaces as they become available, until it doesn't. At any given point in time, each group can continue to develop and test their part in isolation of others, because the interfaces are clear, and have been mocked up early.

Catastrophic failures--through code failures, death, holidays, staff changes, server failures, whatever--are isolated to just the affected sub-project and so do not bring the entire project to a halt as with set-in-stone development plans.

Regardless of whether you use an OO, procedural, or functional design philosophy, or which languages you use, the decoupling of dependancies through interface isolation, is the key to project control and management. RAD allows projects to move forward faster and respond to requirements changes earlier and more easily.

The idea that requirements can be gathered completely up-front, signed off and never change belies the realities of modern life. The last really big project I architected had to change track in late mid-stream for purely political reasons. An election brought about a change in flavour of government, and the project leader was called in front of a standing committee to explain why there was so little regional involvement in the project. The hierachal RAD development philosophy allowed the project to respond to the changes mandated by parliament with minimal delays to the overall project timelines.

I cannot imagine re-carving the stone tablets of a waterfall development project plan, in similar circumstances, without it having a huge impact on timelines and costs.