I actually didn't mean to imply that there aren't situations where something like UML can be useful e.g. documenting business processes.
However, my own view is that as you actually get closer to code the benefits of the "UML as blueprint" style of thinking become less obvious to the point where they actually can hinder a lot of projects (e.g. artificial distinctions where you get "architects" who only create UML and through it over a wall to "coders" who attempt to turn these designs into working systems).
That's not really a complaint against UML. I'd be equally (if not more) disturbed by an office where "architects" only create informal diagrams and throw them over a wall to "coders".
However, that doesn't mean that UML can't be beneficial when used properly. For instance, I could see using UML as a reference rather than a guide (especially if it's auto generated). I've worked with codebases that I wish had a "map" that I could look at to get acquainted with them.
However, my own view is that as you actually get closer to code the benefits of the "UML as blueprint" style of thinking become less obvious to the point where they actually can hinder a lot of projects (e.g. artificial distinctions where you get "architects" who only create UML and through it over a wall to "coders" who attempt to turn these designs into working systems).