In practice in most industries, most folks can probably get away with just knowing the ISA/HASA type stuff and 1..N, * arrity, etc. Swimlanes are also somewhat useful as a concept (but so are regular flowcharts).

There's a whole other ton of UML (see 5/7th of Rational Rose around the early 2000s, which is probably gone all deep and crazy now, etc) that is, IMHO, pretty skippable.

I've not even seen some of the "stuff you have to know" (ball and socket, etc) used.

I do think that designs get better when you can draw them, as when they get hard to draw, it becomes conceptually obvious there may be problems.

UML generation code tools running against 1300+ Java classes and making some huge diagram covered up in arrows definitely doesn't work too well though :)

If you don't think the documentation is useful, please get rid of it. But blaming UML for your documentation problems is like blaming English for forcing you to rewrite comments that no longer make sense.

My sense is that people associate bad processes and bad teams with the tools that they were using. Crappy tools exist, and people have had some pretty dumb ideas about how to use UML, but is useful as a way to express aspects of your design that may lend themselves to a more object-oriented approach. This is something for which no other widespread diagramming language exists.

Whether you're using an iterative or waterfall approach, at some point it is necessary to provide some context for your software units, like explaining how they are associated or what their areas of responsibility are. That's all the documentation does.