Last year, I used the UML static object modeling notation for understanding and documenting an existing RDBMS schema. Also last year, I used some of the UML state modeling (or Harel Statecharts) for getting the UI right for a SwiftUI app. Earlier this year, I used DeMarco-Yourdon DFDs (but we can call it UML) for business process modeling. (And our director of marketing picked it up instantly, and even had an insight into some structure of the data flows between some processes, because of this formalism.) And I'll probably use UML imminently for a new schema, if it turns out to be nontrivial.

I used to use UML (well, OMT, but fortunately Rumbaugh's notation won over Booch's for UML) constantly, when I was doing lots of Java. I worked on high-end CASE and methodology, and on the side I made a convenient little tool to help go from OMT to Java, and keep it up-to-data (in conjunction with Rumbaugh's own OMTool): https://www.neilvandyke.org/jomtool/

One thing to know about these system analysis&design methodologies (before UML, there were maybe a dozen prominent ones) and their various diagrams is that the user bases seemed to change over time. If you were a technical developer of a large system, or maybe a certain kind of big embedded systems developer, you might use it. If you were a database architect, there was a different camp for that, and they had different needs and tools. At some point, maybe around the time that Java was adopted for corporate internal IS development, the UML I occasionally saw was usually simply as a way of visualizing class inheritance hierarchies (and summarizing their Java attribute and method signatures). Which is fine, but it's only a fraction of the benefit they could get from higher-level modeling and documenting, with even that one kind of UML diagram.