It’s funny how you classify something as ‘practically nothing’ while I find it nothing to be sneezed at. 
Can’t all your complains be traced back to the skill of the person using UML? Now I’m not trying to aim at that UML is not for mere morals or some other form of elitism, but rather; are you sure your expecting the right thing from UML? If the design is bad it will be bad regardless if you scribble it on a napkin, use verbal or written human language, UML or actual code.
But arguably actually working on a title, a lot of documentation doesn’t make sense. In part because a lot of games actually get ‘finished’ as opposed to a lot of other software out there. Stuff that does get build for the ages gets locked up in game middleware, cause if it was ‘hard’(/time consuming) you want to reuse it for your next game. A other aspect is that your stakeholders/ user roles hardly change from game to game. As do other circumstances As there is probably a whole tool chain there is also little need to document how those pieces are going to have to work together as it going to be ‘like the last project’.
Design up front is going to always suck if you can grasp to consequences of your choices, but I ague that UML as little to do with it. UML only comes into play when you have to communicatie something in the first place, given that recognise that diagrams(over text) can help convey information better. And then given that u are goign to use diagrams, you might as well use the standard as opposed to creating a new dialect. The question shouldn’t be ‘UML for games?’, rather ‘How much documentation for games?’.
MHO, when coding in Java, it is damned nice :
- to not need a glass ball to tell the future.
- to be allowed to sort out stuff at the right time, which is sometimes right away or ‘just in time’.
- to have the control that we do.
- to have the tools that we do.