I think the biggest one is the "rot" problem. Software iterations have gotten faster (in general, not just due to agile) and it just seems pointless documenting

I think the biggest one is the "rot" problem. Software iterations have gotten faster (in general, not just due to agile) and it just seems pointless documenting things separately with diagrams when so often they have a short lifetime of accuracy. Then, not having a good text representation means it does not play nicely with version control which compounds it all (how can you get the right version of the diagram for the specific software). It did not help at all that the UML tools were typically expensive so only the ivory tower architects would have them so most of the team couldn't actually edit the UML. I do remember a phase where I used TogetherJ extensively as a full round-trip UML tool. It very nearly worked to the point where I could edit things on the UML diagram and the dive into edit the individual classes and methods in code. PlantUML has done a lot to help with this for our team. The slowly evolving convention of embedding PlantUML/Mermaid into Markdown and / or code comments is starting to enable a more maintainable / agile way of doing this. In particular have found Znai recently as a nice tool that brings all of this together along with code extraction to make nice "user manuals" comprised of documentation in markdown format and code comments.