I've used UML since it was invented in the '90's and have used it in companies large and small for a wide variety of purposes. I use UML for two fundamental purposes: as a scratch pad for thinking (sometimes I don’t know what I think until I see what I draw ;) and as a way to document and communicate designs. Here’s how I use it and some of my rules-of-thumb.
I use UML when other tools are inadequate for visualizing/modeling. So, if you're using a SQLServer database, you can use the built-in design diagrams and print and paste them into your documents. UML is not needed here.
In thinking out design problems, I often start with a wall-to-wall whiteboard and once the design crystallizes, I move to UML diagrams (or move back and forth from monitor to wall).
JavaScript and Ajax development. Tool and visualization support is weak. I use UML to think through and show the high-level design of complex JavaScript apps. (If you’re working on a Java app, you can use the tools built into most Java IDEs to visualize your code. On the other hand, if you’re working on a JavaScript app or have poor tools, this is harder to do, so UML can fill in the gaps.)
Information architectures and navigation for web-based apps. I use UML to show web pages, their relationships, and information components on web pages. The same also applies to screens in any kind of GUI (it used to be called a user experience model). I use REST urls in my web-based apps. So I annotate my page objects to show the actual REST URLs. That way, I'm simultaneously thinking through the REST part as I'm laying out the pages. In my experience, this is one of the most useful and underused types of diagrams—perhaps because it’s not standard. It captures both the information architecture (your domain model experienced as a collection of pages/screens) and the concept of the application as a set of navigatable views. Frequently there is a mismatch between this model that is the closest to the user and the application domain model or the database model. Being able to have this model fleshes out the problem. I’ve worked on projects where everyone had their model of the app to be built: the usability people, the developers, the database people, the enterprise architects. But nobody had the correct model and the user experience model fleshed out what they weren’t seeing.
Code-based models. I work with Java and reverse engineer the codebase and create diagrams to document the design. However, because the Java tools are so mature, I infrequently need to reverse engineer to just to understand the code. I'm using Enterprise Architect which is inexpensive and allows you to reverse engineer new code and sync it up with UML diagrams based on older code.
I put all of these different diagrams together in one project and it depicts the total design of the System as a set of views. I also export my UML projects to XML and store them in my version control system. Diagrams are published on the Intranet and inserted into documents.
Component diagrams, never. If I want to depict components, I just use a class diagram and annotate it with a stereotype: page, view, table--to represent the type of object I’m depicting. That keeps things simple for me. I use stereotypes heavily. They allow me to essentially create my own diagram types and yet stick to using mostly class diagrams.
I use sequence and activity diagrams infrequently, but they can be indispensable and powerful at times. Sequence diagrams in the design phase when you are working out the interactions of objects. The more complex the interactions, the more you need sequence diagrams. (When the sequence diagram is too complex, that fact might indicate that you need to simplify your design.) I have found sequence diagrams most useful when reverse engineering a new project that I inherited and need to get up to speed quickly. I’ve found that they can give me a competitive advantage in understanding Systems.
Finally, I tend to prefer quasi-physical models. Models based upon the actual code to be written or the actual system, but somewhat abstracted and tweaked for communication purposes. Somewhere between the airy abstractions of “architecture astronauts” and intricate code-based models with too much detail and less value than the outline view of your IDE.
So to sum up. I use UML for thinking and for documenting and communicating designs when there is a need for better visualization and when other tools fall short.