I had a look at this, but I'm having a pretty hard time telling if these diagrams actually make things more straightforward. My guess is that quite a few people would find a pseudocode listing more readable, but I'm open to alternative takes.
Diagramming is very useful. I just don’t see the value of dogmatically following UML-style formatting.
From the authoring side it helped that it was UML because that meant I had a standard language for defining the diagram with plantuml.
I was thinking about this conversation overnight, and I wonder if a “UML 2” or “UMLite” that had a very limited vocabulary and a narrow set of use cases would be well received. Basically, not “here is how you can describe every noun, verb, and relationship in your enterprise so you can automate them” but “here’s how we draw classes, databases, and sequence diagrams to communicate with other people”. I’d be all over that.
I suspect more people could benefit from using it if they spent time with it. I don't think I'm that odd. I was around when writing automated tests was becoming common practice and I saw all the resistance and hate for something that is hard to know the benefit of until you do it. That might be in play and I suspect a lot of the resistances was because enterprise software development tried to make it into some oppressive process.
Here's an example design I made last year that features UML diagrams that I think are useful: http://flutter.dev/go/multiple-engines