As the resident Diagram Maker at my job I really appreciate any and all discourse on the topic. Knowing the purpose of your diagram is a hugely under-appreciated part of the process. Service flow chart or system architecture? High level system overview or actionable, followable flow-chart? The engineer in me always wants to put All The Things in the chart, to make it maximally "correct". It's never the right move. But how to make it clear what's included or not, and why?

I still struggle with finding the best approach each time; I'd love more discussion of this stuff.

Just because you said that you were interested in some Opinions, one of the least appreciated aspects of any documentation (but especially diagrams) is defining who the stakeholders are at the start of the document. It’s the difference between having frustrated users who can’t understand things to happy users that understand limitations.

The corollary to this is that the best diagram that boundaries are often along communication lines between teams. This is Conway’s law all the way down. And the reason is that most often people use diagrams to get a spatial sense of where ‘they’ fit into things. I have only anecdotal evidence for this, but the most helpful and lasting diagrams I’ve ever made are when 1) they define (and stick to) specific stakeholders, and b) they are delineated by groups/teams.

Multiple interlinked diagrams? A whole bunch of diagrams at different levels, from different perspectives all designed to answer different questions?