As for your questions:
# We use UML, but jumpstart the process by using a standard template that identifies the simple diagram types we tend to use, and minimizes the total number of UML element types.

# A standard diagramming notation is important to me, because an architecture document, lightweight or not, will have a reasonably diverse audience. That being said, I think the diagram needs to be simply built, and easy to understand regardless of one's experience with UML.

# Absolutely. If your diagrams are only readable to the most "elite" of architects, you've failed on your goal of communicating a design.

# "Enterprise Architect" The project templating offerings are great, and the ability to export a suite of diagrams to .rtf files is great for communicating with a diverse audience.

The only UML diagram I find much use for in real work is the sequence diagram, the one that actually displays the system as it is in life. Writing this sort of diagram actually makes you work through the responsibilities and collaborations between your moving parts.

The all too common class diagram is more like the software dead and pinned out on a dissection board. By itself, it can only be a guess at what the bits actually should do, and could be quite wrong.

As for the other diagrams -- well, the idea is to write code, not draw pretty pictures.

A spec needs to clearly communicate what it is specifying, and here I find that UML largely either communicate things that are too vague (I've yet to find a case where use case diagrams [as opposed to written use cases which I DO use frequently], have actually been worth the effort for example), or too low level for specifications in most cases (state diagrams for example - they clearly have their place, but more often as documentation than specification, because again most people don't understand them correctly).

Use case diagrams are perhaps the worst ones - I find that invariably when I've had to deal with specs full of use case diagrams, the diagrams cause people to get more confused, not less, about what you are trying to convey. That includes developers, but is most prevalent when dealing with other stakeholders. I can usually convey far more information with a couple of paragraphs of text, and be confident that there is far less room for misinterpretation.

As for specifying the data model itself, I've yet to find a developer that can't just as easily understand a textual description of it. With ORM's becoming more and more commonly used I've also seen an increasing tendency that the developers I work with tend to prefer to see model classes in code rather than diagrams, because it's the same amount of typing (and far less wrestling with poor UML tools), and the latter they can trivially develop in conjunction with a test suite so they know it makes sense. I've also yet to meet in person a developer that didn't strongly hate UML, though probably mostly because the tools they've had to deal with (Rational tools being pretty much at the top of the hate list) are amazingly crappy.