Sure, there is a tradeoff between the desire to write inferrible code and hammering code out quickly. This is sort of the entire dynamic/static language discussion. Clearly, there are advantages to both.
There is an analogy here to code performance. Writing fast code is also harder than writing code where you don’t care about speed.
For both performance and staticness, Julia happens to be designed in such a way that they both can be achieved with minimal effort compared to other languages - though not, as you say, zero effort. There really is a price to pay for writing fast and/or inferrible code.
Staticness and performance is also similar in another regard: Not everyone cares about performance or staticness, and most people only care about them in some situations. However, there is an asymmetry: One cannot write fast code if one depends on a slow dependency, nor can one write a static program if one uses a type unstable dependency. On the other hand, there is no problem hammering out quick and dirty code that depends on a fast and static library.
When writing applications, one can do as one pleases. But what should one do when writing generic libraries that are to be used by other people for use cases that you cannot completely predict?
My take is that one should strive to write fast and inferrible libraries. This way, you give your users opportunity to use your library for both fast and slow code - and for dynamic and static code.
To me, the fact that you can do this at all is the most beautiful part of Julia. Most people agree that smashing the two-language problem is a major selling point of Julia. To me, there is an analogous “static/dynamic two-language problem” which is the major theme of the OP. Julia isn’t there yet, in that it doesn’t provide good static analysis even for inferrible programs, but it’s technically possible for Julia to have a static dialect in a way that it is NOT technically possible for Rust to ever allow scripting, and I really hope Julia eventually allows for this.