You missed the whole point of the paper and built your own castles in the air on your misunderstanding. Parnas and Clements were not saying that Waterfall was the best way to design things. You also have to bear in mind that they were, for the most part, dealing with systems that would have a long life and would need to be maintained. For this sort of system, it is essential that future maintainers not only know why decisions were made (“it was fun to try a new algorithm” isn’t good enough), they must also know how those decisions support higher levels of abstraction.
Taken over a whole system, the only logical conclusion is that you need to produce a complete set of information at each level of abstraction, from user needs at the highest level to the detailed design and code at the lowest. And those sets of information need to be linked so that you can see the relationships between atoms of information at each level and (usually) the justification for the relationship. Whether you build those from the middle-out, bottom-up, top-down, or some combination really doesn’t matter. Inevitably, that means that you produce material that looks suspiciously like that produced in a waterfall. And that is fine. And it is also entirely consistent with Agile, unless you are one of those misguided idiots who thinks agile means you don’t need documentation.
You also wrote:

If software engineering is in its adolescence, however, the critics’ proposed cure is downright childish. … On the road to maturity we put away such childish things as the idea that the world could be simple, if only we pretend fervently enough.

Calling the cure childish is insulting and again shows that you did not understand what they wrote. They are not saying that the world should be simple, far from it, they are saying the world is complex, and you need a way of handling that complexity.

Utopian step changes to the system that discard feedback loops are as far from the basis of good engineering practice as it is possible to get: ‘they violate nearly every known heuristic of engineering.’ Nobody becomes an engineer with a panglossian belief that we live in the best of all possible worlds. Yet we must not fear the real world and seek to retreat into a land of make-believe, for the very thing that makes engineering necessary also makes it possible.

What gave you the idea that they discard feedback loops? That is as far from the intent as it is possible to get. Yes, use feedback, all the time. It is essential. That feedback gets captured in the documentation (“we tried this and it didn’t work”). The proposals in the paper are a result of living in the real world, not fear of it. There is nothing make-believe about “Fake It”, despite its somewhat flippant title.
It might be worth mentioning that the “V-Model”, which has been used successfully in systems engineering for around three decades, started out as a sequence, like an extended waterfall, but is now generally recognised as being more useful when treated as a flow diagram between processes that can be concurrent. Which is pretty much what Parnas and Clements were advocating.
You are far from the first to misunderstand the paper, and I am sure you won’t be the last. Which is a shame, as it’s real message is pretty clear to those who read without blinkers.