I used to whiteboard for this, but that hasn't carried over well in the remote world. PlantUML is my friend here because I can knock out ugly but gets-the-point-across diagrams in 30 minutes before a meeting and check them into source control, so I can then take the bones of older diagrams and rework them for a fresh meeting. I've taken a throwaway approach to diagramming, where I'll produce them more or less on demand for a meeting or presentation, but not think of them as an enduring artifact. In contrast to the other UML diagram types that have strange notations and the information is more densely packed. Yet sequence diagrams are useful in a wide variety of use cases, and let's face it, they're the easiest ones to comprehend, and are even understandable by a non-technical audience. Most developers IME actively reject these diagrams because they are quickly outdated, or require constant changes to keep up to date, which is true, but this is not unlike documentation, comments, and a myriad other things that needs to be synced with the code. The drawback of this, of course, is that with the Agile approach these diagrams never end up being made, so developers are left to assemble their own mental model of the system, which hurts the overall comprehension. So we saw no need for these visual design tools to model the entire system, since we ended up changing the design during the lifetime of the project anyway. The industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers.

The only reason the other diagram types fell out of favor is because of the development methodology change starting in the early 2000s. Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually.

I also find sequence diagrams to be the most useful, but disagree that the rest of UML is useless.

Sequence diagrams if else