Maintaining any documentation can impose overheads that many smaller teams in smaller companies often can't afford. Diagrammatically focused documentation in particular can be difficult to maintain if the tools aren't very simple to use, and often programmers find themselves spending more time struggling with formatting their documents than they do writing the code behind it. I can't think of a single diagramming tool (specialist UML or otherwise) that allowed me to create even simple UML diagrams quickly and easily. Sure if I really put the hours in, I could get a beautifully rendered diagram, but at a cost of lots of hours spent fiddling with software where the input interface was poorly-thought and which made a mess of what should have been a relatively straightforward task.
Personally, I prefer to use a white-board, draw up some rudimentary UML diagrams to compose thoughts or to describe something to someone else, take a photo of it with my phone, and that becomes a part of my planning documentation if it is really needed. Otherwise I use UML/diagramming tool very rarely if ever at all, since it is not the core of what I do as a software developer.
So in short, using UML isn't the problem per-se. Documenting large projects in UML is, particularly when the tools seem to always let you down, but also because the time spent creating the diagrams can often take longer than the actual coding.
Software architects and planners looking to secure large corporate or government projects may need to use UML more, but for the day to day developer, formal diagramming is likely to be overkill for the most part, and this is probably why it is not as widely used or accepted by the more experienced of us. As for the newer developers out there, it's likely they simply don't see the need, or don't get a chance to use it in an industry that has largely put aside the need for high documentation overheads. This last statement is probably more true of the agile teams out there. In any case, once you have a working product that meets all of its requirements, if diagramming is needed (for posterity if nothing else), then there are tools that can generate the UML for you straight from the code, and keep it updated if the code changes, and this is probably the biggest reason of all that UML is so seldom used, because changes to diagrams often result in changes to requirements which can be a cause for missed deadlines and create difficulties when a developer or even the customer needs to negotiate a change in requirements.
So I feel it really comes down to how UML is used as a tool. If it is over-emphasized in it's importance, it becomes a burden. As a means for developers to discuss design and use-cases, it can be a useful tool in an informal setting (such as at the white-board during a meeting).
In my case therefore, I stopped using the diagramming tools when I realized that the cost/benefit to me became too out of balance. As for UML itself, I use it in an ad-hoc manner, and thus the diagramming tools are no longer particularly relevant in my case.
