UML is really powerful but definitely could be more simplified to just be basic charts. The problem is that sometimes you need to see the full complexity to be able to start simplifying systems. The real issue involving a decades-old process that gets in the way isn't actually UML though it appears at first to fit that description. It's actually scrum. Scrum-based methodologies on how to deliver value to the business. Scrum eventually forces engineers to make trade-offs like how thorough their UML and regular flowcharts can be which is not a scalable way to build quality products. The charts should be precisely as complex as is needed to accomplish the business objective and ensure that the business is always able to be in the best starting position possible to continue working on a piece of code or a system with just that documentation as the starting point. Sometimes this does mean that a demo may be just a bunch of UML or simpler flowcharts that have more breadth instead of user functionality.

UML makes sure that product functionality knowledge can be more easily restored or understood from an engineering mindset. It encodes a lot of information into the format and simpler options exist too. But I have to say once again that you almost got it right as to which decades-old development methodology is pretty deprecated despite still being in fashion - it's not at the diagramming layer, it's at the project management layer.