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.

Agreed, I've found that the more time that's spent trying to shoehorn an implementation to match a spec to the letter, the longer it takes to ship.

So long as the delivered system does everything it's supposed to do, the plumbing doesn't really matter as much.