A particularly important variant of this technique is when I am working with a domain expert to try to understand the domain for which we are building a system. In this situation, I use minimal notation and concentrate on the concepts in the domain expert's head rather than any particular software situation. I've found it easy to teach this conceptual modeling style to people without a software background. Then, using the diagram, we can jointly develop a well-defined vocabulary to talk about the domain and can come up with abstractions that are useful both in discussions and in the final software. This was a great boon to me when I worked with complex domains such as healthcare and financial trading.
Standardization is valuable here because it enhances communication.
It's difficult to communicate with people when they use a variety of diagramming styles. By having a single standard, we can be sure that if people know any diagraming styles, they will know this one. But don't let this go too far. The UML contains a lot of notation, and there's no rule that says you must use all of it. Try to use a fairly minimal part of the notation, and don't use the advanced concepts unless they're really necessary.