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.
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."