This is an understated truth about most iconic notations let alone anything instrumented into a CASE tool. That is that the Agile movement introduced a meanness and immediate gratification factor into the very idea that modeling software was useful or necessary. Concepts as simple as an input arrow going into a process would enter from the left of a circle or box and the output would exit from the right were the object of debate and ridicule.
Why bother? Skippy, the agile programmer, had already coded something up that happened to feature the end-users favorite color.
Eye candy always trumps rigor and deliberate modeling of components.
Formal notations didn't stand a chance.
(This assumption I think is sorta analogous to how we knew waterfall and even spiral were hard, and that many teams would need help to deliver successfully... then someone told those teams they don't have to work that hard, if they instead operated more like situated action reactive agents instead of planning ones... and then the default impression became that people who did waterfall/spiral must not have been as enlightened as ourselves, and we have nothing to learn from them. :)
I could yammer for hours on methods and tools, but I'm more passionate about other topics right now. I'll just quickly point out one barrier to uptake of UML...
One of the barriers to the modeling methodologies was that many people didn't know how to use them, and so presumably didn't see benefit. That they didn't get it was obvious when you'd see diagrams that were simply wrong, or that expressed no information other than being a not-very-helpful transliteration of code. And a lot of the examples people saw also had this problem.
A memorable epiphany I had was shortly after joining an R&D group for next-gen OO CASE. One of the senior people was describing some complicated unfamiliar thing we had to understand, and using an OMT diagram to do so, pointing to things on the diagram as he explained... and it clicked: I was understanding so much from a diagram, and we couldn't have gotten that from code.
I then learned all the other modeling things, and set about to design an approach to make it practical to use them all sorts of places (roundtrip, methodology flexibility, better HCI, etc.). Then business things happened, maybe because Rational was locking in an industry shift with what was turning into UML, and so I instead went to work on Web and HCI&AI hybrids.