I believe all of these statements to be true.
I had a contract many years ago with a large insurer. Their development process basically consisted of drawing really complex UML diagrams, then hitting the Big Red Button and having the modeling tool generate 40,000 lines of framework code. The chief architect explained to me that really the only work required was just a tiny bit of business logic in the appropriate places.
Fortunately I was not part of the main dev team, which for some strange reason (at least in the lead architect's mind) had the damnedest time with this system. My job was to create an internal permissions system. Given app X, user Y, and action Z, was the action allowed or not.
I looked at the problem for a while, and no matter how I thought about it, to me I had three lookup tables and one method. Boom, I'm done.
The lead architect wanted me to still draw a diagram with one class, push the button, and get the 40,000 lines of code. For some reason, this did not appeal to me.
Took me about 3 weeks to convince him that really 20 lines or so of code was all we needed. I still had to draw the diagram, though.
That's the horror story -- one among dozens I have. But on the flip side, I've been with teams that interviewed the customer while sketching out a domain model. Since we all understood UML, a quick and lightweight sketch using the appropriate notation got agreement on a ton of detail just taking 30 minutes or so. That would have been very difficult using a conversation or word processor. Sketching without some common lightweight understanding could have led to rookie errors.
There is nothing in this world better for getting quick technical agreement on complex problems than group sketching using lightweight UML. The trick is sticking to the absolute minimum.