Not long after I started training people in how to use the UML effectively in the context of the Iconix process, I came up with term "magic triangle" to describe what seems to me a potent combination of artifacts. Specifically:
1. protypes (which includes anything that provides a picture of a UI, from a sketch on a napkin up the chain)
2. use cases (which are, of course, part of the UML)
3. domain model (made up of UML class diagrams)
Each of these pieces does something well. The combination, with each piece reflecting some things that complement the other pieces, is powerful.
So, why am I bringing this up here?
Two things. (1) There's no reason why people shouldn't learn how to write and/or use use cases because of fear of the UML. Use cases are about capturing what a system needs to do, specified in user-friendly language. (They were a part of the Unified Method early on, albeit a late addition. They've never really been a full player, partially because Dr. Jacobsen was late to the party and partially because they're, well, text-based in the context of a primarily visual langage.) (2) Class diagrams are indeed at the conceptual center of the UML, but that does NOT mean that people should be afraid of them either. They're excellent at capturing the vocabulary of a project, when expressed at the appropriate level of detail (which is to say, just names of classes). These are, in my mind, absolutely fundamental tools in the BA toolbox.
I'd say that a BA should also know his or her way around activity diagrams (UML 1.x version, at least; I have some issues with UML 2.x activity diagrams, which I think introduce unnecessary complications), definitely. Judicious use of state diagrams to show the lifetime of objects at, again, a more conceptual level is also a very handy technique. As far as the rest of the UML, I think you just have to avoid the temptation to dive too deep too soon, but as someone pointed out, the more tricks you have in your bag, the more flexibility you have.
I'm not much on 1-10 scales, and of course, I'm (more than) a little biased, so I'm going to avoid reducing what I've said here to a solitary number. I do think, however, that since the UML was explicitly built on the premise that use of it would improve communication between and among project workers and stakeholders, there's very good reason for a BA to learn the language, and for said stakeholders to be open to learning those aspects of the language that will add value to their lives.