"An occasionally invaluable tool" is how I could describe UML diagramming.
Design documents, such as sketches, artists renderings, specifications of performance, etc., may or may not be useful to the engineer producing the blueprint. The discussion of UML is at the level of these artifacts. If UML is useful, I want to look at it and have an idea of what the software is going to do. Some parts, like event-state diagrams, activity diagrams, and use cases, are pretty good at capturing that design in a way that I can talk about it with someone who doesn't understand code. I would not pay someone for completing a document like that, though, not until it was reflected in code.
Another way of capturing design is through functional tests. Look at projects like Fit for examples of how that might work.
And besides what is the relative share of skunk works type teams from the overall software development market?
1. To make theory more closely match practice that already works. This gives teachers something to teach.
2. To make someone who doesn't know what he's doing appear as if he did. This gives consulting firms profitability.
3. To help organize the System Development Life Cycle (waterfall process) of very large projects. This gives someone who knows what they're doing a few more tools in their toolbox.
My take? If you've really found good use for tools like these, then your project is probably too big. Break it down into smaller pieces, build a prototype for each piece, get feedback, and refine. It's not how quickly you appear to get started; it's how soon you deliver something of value.