When you don’t write them down, you’re saying, “trust me, this works.” But now the types are written down in your head (a very volatile form of memory that can’t be accessed easily by others).
One time when dynamic works well is when “prove this works” is simply not worth the time. Eg. a quick script.
Which is only even true during the initial phases of a project. The moment the initial team shares bus numbers with other developers, the 'you' becomes a collective you, and you have three people who all believe they have it written down in their head, and often at least one is wrong.
You can make a project that relies on memorization. It will eventually fail, in one sense of the term or another. Or you can make it so that you can verify things you think you used to know about the project cheaply. But then you need to remember to check your assumptions when doing new work.
Note that "types have been written down" != "the program was written with static typing". See, for example, what's doable with clojure.spec.
While loose, "from the hip" code (w.r.t. typing) often correlates with the use of dynamically typed languages, we shouldn't make the mistake of assuming a total causality there.
(Also, I still find the number of people willing to put e.g. `object` parameters in their public C# APIs concerningly high. Not that one has to deal with such APIs all the time, but they're not exactly eradicated, either.)