Earlier quoted context omitted.
Prototyping takes less time than writing up the requirement in paper. And customers can give more accurate feedback watching the prototype than reading the docs. It rarely happens that once a prototype is written, the developer finds out it was all a wastage and the customer wanted something quite different. Think of the prototype as a Photoshop mock, but interactive like the real application.
You aren’t writing up UX requirements. You’re writing system designs. If you’ve never had to write down and get feedback on a system design that is entirely okay, but as you work on projects of increasing complexity and scope, it becomes more and more important to plan before you write. The prototypes you’re describing are primarily useful for UX iteration, not system design.
I'll counter that with a real-world experience.
I contracted at a well known company that did system design & documentation first, without doing prototyping, etc. My first day working on the UI I pointed out that the web app had so many menus that the actual content would barely fit on a 15" laptop screens.
The team debated and debated on how to fix it, but ultimately it kept getting trumped by the documentation team who said the docs are done so we couldn't change anything. I left after a couple of months. They worked on it for a year before finally tossing it out.