It doesn't need to be "either move in the direction of total dynamism or move in the direction of static guarantees". At the very extreme end of total dynamism

It doesn't need to be "either move in the direction of total dynamism or move in the direction of static guarantees". At the very extreme end of total dynamism, you get facility to implement whatever kinds of guarantees you want as libraries. Sad that in a language without meta programming features, the power is indeed reduced, but nevertheless extreme dynamism can be powerful enough to implement the guarantees that you need. For example, if JS gets a facility to "run this code when an unknown method of this object gets called" and "-ditto- when an unknown field gets set or read", you can implement a public API for an object using a proxy object. You'll also be able to enforce member naming conventions if you want to. If you're doing the wrapper only for checking, you can keep the wrapper during development and leave it out when you deploy the code. You get a lot of flexibility. Furthermore, if JS lets you install hooks like python decorators, you can implement guarantee mechanisms in JS as a library similar to what decorators get used for. Again, if it gets you better performance, you can strip decorators from deployed code during the minification phase. So indeed, why not shoot for extreme dynamism in JS?