I think there's lots of potential for abuse/time wasting with UML. But consider the fact that when you're writing code, you're often focusing on two distinct concepts: implementation and design.

When designing, you are implicitly asking yourself: "what problem am I trying to solve, what data structures should I use to represent the elements of this problem, how should they relate to one another, what should this system interface look like, etc".

And when implementing, you are focusing on mapping those concepts from design into code. Often during implementation you can discover new elements of the problem or requirements that need solving. So implementation itself is valuable.

But design can be considered and reasoned about without requiring an implementation. Even without a peer to discuss the design with, considering "what if I decompose the data structures this way?" is a valuable exercise. Now, you don't need UML to do that. But you can leverage it to do that. I will posit that the screen-to-brain throughput of a UML diagram is greater than that of code or prose. Also, the brain-to-screen throughput of UML is probably better than those.

You might be surprised at the discussion inspired by a simple class diagram:

"Ok, sure, but which class holds the file descriptor?"

"None -- fred's working on a library that does that"

"No, Fred's library only considers the command line args but doesn't open the files."

I take your point, but for a UML diagram that describes things in levels of detail where those kinds of points can be addressed you could probably throw together a work proof of concept in real running code.

I'm not against diagrams or discussion of design, far from it, I just think that UML is a terrible notation - it makes people think they are working with blueprints rather than sketches.

Rational Rose was terrible at UX, but surprisingly it was a de-facto standard.

Now that was an expensive con. All UML bullshit is a joke: more energy is spent on being Correct than addressing the original issue UML was meant to solve.

To be fair, every modeling tool had terrible UX at that time - save for some domain-specific ones (e.g., NI had a great tool, but it only worked with their hardware components).

Well, imo the statement holds true with any of the UML -> Agile/Scrum(especially True Scrum, when it is your fault when it not works) and Lean/Kanban substitutions.

I wonder whether they are the same people selling bullets in different shades of silver though the ages, or it could be that the SW business is big enough that we can witness different species develop the same survival strategy of going from host to host and sucking their money out in different niches?

If those advocates were sellers, then they were all proposing this as a panacea - and no tool is a panacea. Anybody who promises to solve all your problems is selling snake oil.