Good observation. In Peopleware: Productive Projects and Teams the authors specifically address this phenomenon. Programmer productivity varies widely between organizations and a lot of it comes down to environment.
I got the impression that the paper was suggesting an early, disposable prototype during the preliminary program design phase, similar to what Fred Brooks suggested back in the day. (http://c2.com/cgi/wiki?PlanToThrowOneAway) Meaning that the PPD phase was in effect an initial iteration through the development process. The outputs from that were used to generate the program design documents in the primary development process.
I almost made a comment about that part. But that's the only part that's restricted (and then not strictly) to two "iterations". But I don't think that was what OP was referring to.
> This paper doesn't just describe the waterfall, it explains why it doesn't work and proposes a more iterative approach, albeit with only two iterations.
The iterative steps involved are not the throw one away bit, but the feedback loops in between the different stages of development. And the paper does not restrict its model to two iterations.
The throw one away portion are the prototyping phase, which is the same development process in miniature. Like how, here, we might prototype our radio software without the hardware at all just to make sure we understand the protocol and other aspects correctly so when we do the full development on the radio (often with reused code from the prototype, though) it's better informed. [0]
[0] Though, true to form, the last prototype became a delivered product instead of the basis for the final product. Oops. The dilemma of making a too good prototype, but not engineered well enough to actually be a final product. Maintenance has been a beast.
