The problem with most diagrams is that they lack semantics. What do the boxes and arrows really mean? As soon as you start getting fuzzy, the diagram is effectively useless. If you're up for a laugh, try to play "Diagram Bingo" next time you encounter one:
https://c4model.com/bingo/Structured diagrams like ERD and the C4 model help. But I'm not convinced these add much value over the equivalent textual description (I'd rather generate an ERD from SQL; where my SQL is the source of truth). And importantly, they're generally lacking one important dimension: time.
The only diagram I regularly use for software is the Sequence diagram. It has well defined semantics: actors/components across the X axis with their interactions ordered by time down the Y axis. It's a secret weapon for modeling any system that has a distinct "flow" through the steps. You can immediately see not just what components are related to each other, but exactly how they interact over time to produce the end result. It makes it fairly obvious where every bug lives and where every new feature request must be added. It's the only diagram that I cannot replace with prose or a high-level programming language.
And even still, it's worth "writing" your sequence diagrams instead of "drawing" them. Mermaid's sequence diagram markup is lovely and renders directly in GitHub.