1) It's faster to write the initial proof of concept with a dynamic language
2) It's common that the proof of concept becomes sufficiently big/stable that it turns into the final codebase
3) Gradual typing makes the path from PoC to real codebase smoother, instead of re-implementing in another language.
Point 1 is contentious of course, but that argument isn't relevant here. It is believed, and that belief becomes practice.
An example of point 2 might be OSH of the oil shell, which doesn't use mypy I believe, but was originally written in python with the intent to rewrite in C++, and eventually decided it was too costly to rewrite (somehow he decided that ripping apart the python VM would be the more fruitful path... and apparently he's making good progress there).
So basically, the usecase of mypy is when you're making the decision of continuing with python, or rewriting. Sometimes rewriting was part of the strategy from the start, other times a script just grew into a full-fledged program over time, but mypy's primary goal wouldn't be to introduce from the start.
Another usecase I've personally done is having the typing available to me from the start, but not actually making use of it until I reached a particularly nasty section of code. And so that particular chunk becomes (reasonably) statically typed, while the rest of the program remains standard python.
Although in that case I used a library that enforced typechecking at runtime rather than mypy (the library was typeguard iirc), which I only enabled on test runs (it slowed down the program significantly).