Underneath the good ideas of UML was the idea of model driven development - that you could generate code from the models.

Good diagrams are an art form though, just like other forms of good documentation. There is a big difference between a diagram being a normative source of truth, and being a good tool.

Take this diagram as an example: https://takaakit.github.io/uml-diagram-for-ddd-example-in-ev...

* Nearly the top half is taken up by relations which aren't especially helpful, and would be better expressed on the entities themselves.

* The "Location" type looks like the primary type in the system based on nearly half the types in the system connecting with it, creating a nest of graph edges. However, this is likely a simple and immutable record type. If the entities in this diagram had attributes (e.g. like a class diagram), you could refer to it by name, and greatly simplify the cognitive load in understanding this picture.

This is the sort of diagram that gets generated from code, and is at the level of specificity needed to generate code from a diagram. It also isn't very useful for using the model to convey the system to a person - a developer might be more comfortable reading the code rather than looking at a picture generated from it.

IMHO, that split focus in UML between people and tooling greatly reduced the overall usefulness and understanding of the system. It gave UML a bad reputation. Training on MDD tools prevailed over providing a baseline of common nomenclature to enable "team cave drawing on a whiteboard", which has no commercial tooling or market other than the whiteboard and markers.

The areas where visual languages have a bit more prevalence are on the business modeling side, including things like network architecture diagrams.

It is a bit of a shame - going through a set of use cases while iteratively improving the architecture by improving a set of class, sequence and ECB diagrams is something I always found to be crazy efficient vs diving immediately down to prototype code.