In my opinion, by and large, any big problem is tackled by breaking it down into smaller problems.
Diagrams, assist in this task. The provide different views/details of the system. At times you are interested in how database schema will look, but other times, you are intersted in how the components will talk to each other. Perhaps, you want to see details of how a particular algorithm will work. Either ways, there is a way to depict a problem/scenario with a diagram rather than text.
Benefit of a diagram is that you don't have to have as much text. Picture bieng a thousand words and all.
For each use case, there is a different level of detail, and different kinds of things need to be thought of.
So in summary, I think it should be a pre-requisite to be able to read those diagrams well, so everyone in the team is on the same footing. The actual task of creating those diagrams, well some are more adept than others, so I would draw the line at reading them. Creating would be a bonus.
UML is a popular notation. One should be familiar with a common subset that is used more frequently. There are details in the standard, that probably only the super experts know about. One should have functional knowledge.