My personal opinion (based in part on HN):

- In a nutshell: everyone should know about UML and how some relevant diagram types look. Nobody should use it religiously.

- Diagrams are great tools for communicating ideas and implementations on an abstract level, and for interactively thinking about ideas that can be drawn in some way. A diagram can also visually highlight problem areas (e.g., components with many dependencies).

- Good use cases for diagrams in SE are e.g., explaining high-level architecture to someone, thinking about and refining database schemas, documenting interaction flows, or giving an overview of class structure in automatically generated code documentation

- It is nice to have visual consistency - it makes parsing a diagram so much faster and less error-prone. UML provides sensible guidelines or inspiration on how to draw e.g., a sequence diagram or a class diagram. There is no need to re-invent the wheel.

- In most cases, knowing about the diagram types and their approximate design is enough. As probably very few people know what the different styles of arrows or boxes might mean, it is a good idea to annotate important elements with their meaning.

- For thinking/communication, drawing diagrams by hand is the best way. Excalidraw/tldraw are nice for stuff that should go into static documents.

- Documenting the state of a system with manually generated diagrams is tedious and requires constant updates. A better way is to auto-generate e.g., class diagrams using PlantUML or Mermaid.

- Nobody uses UML for designing complex systems and then auto-generating code.

The startup I work for is pretty flat. There's the chief product officer who is actually pretty technical, the chief technical officer, and engineers basically.

We use UMLs and flow charts in miro to diagram things from both a high level (for product to understand) to intricate details.

It works great!

I've personally found sequence diagrams to be immensely valuable the handful of times I've worked with them. Both for documenting the intended way to use an API and for analyzing the ways the different components of a system can interact. This has often helped me escape my tendency to focus on the happy path when analyzing systems.

Having architecture diagrams is not fundamentally a bad thing, and standardizing the conventions for them is not fundamentally a bad thing. I think the thing that gave UML a terribly bad name was the cavalcade of early "zero code" or "low code" tools trying to turn your UML diagram into code; those were terrible.

Certain UML diagrams can be useful for high-level documentation or for teaching concepts.