If it's just co-workers then there's one set of reasons. If it's management, the only argument I've found over the decades is "Reduction of Risk". If you have a good model (NOTE how I'm not talking about documentation), then you can interrogate the model more easily than testing in real life.
If you are seeing the model as a documentation mechanism then you have missed the point and it's probably best that you don't embark on the process as the outcomes are almost certain to be sub-optimal (and we saw what happened to sub-optimal mortgages in the last decade...).
If you are documenting an design not developed within the model, then you are modelling outside the tool and all you are doing is adding overhead without being able to leverage any power in the model.
For me, one my theses has been that actual modelling in the tool gets around the problem of "seduction by narrative", that is the phenomenon of reading a passage of text (say in some specification) and it seems fine, but when you try to apply some real formalism you find that it is sub-optimal.
On the other hand forcing everyone to exist in the same reality has a beneficial effect as you can interrogate the model to "compare and contrast" one projects view versus another (or in our case, the "Enterprise" view).
One essential issue is that modelling before implementing is a "paradigm shift" - usually accompanied by scotomas on the part of the non-adherents. With any paradigm shift, when you're on the before side, you can't see why you should change and once you've "seen the light", you can't see why you couldn't see it.
Use the model to design and check your proposed solution. You'll save a lot of time and energy that way.
As others have implied, the documentation we normally produced, is conceptually a snapshot of a properly created model, but it's the model that counts.
HTH,
Paolo
