Earlier quoted context omitted.
It doesn't have an adequate type system. There are too many silent conversions. The syntax is very clunky. All the object systems feel hacky and they can't be relied on to interoperate with each other. Problems like no standardized threading support or decimal type could be resolved in the future. But the language as it exists currently lets you override everything, and that's the sort of thing that you can't remove…
I think Typescript solves a lot of these problems. The type system is amazing, conversions are explicit. Syntax is slightly improved, built-in class system. The others I don't really mind: I like writing event-loop code over threads, and have never once run into Object.prototype problems in the wild.
First, running the same UI code on the front-end and back-end will enable the best performing apps across platforms. Imagine being able to run a rich client on a powerful PC that just talks to an API and does all the rendering as a single page app, while simultaneously being able to serve up pure HTML/CSS to mobile devices and search engines. Being able to run code on the server or client as needed solves too many problems to ignore.
But on the other hand, javascript flexibility and lack of type system will inevitably cause problems as the codebase grows unless you have a good lead developer to define standards and an iron-fisted approach to code reviews.
Personally I think coding standards are a stretch with a language as wild as javascript, and a higher level language to enforce certain things is the best way to reconcile these two problems. I can even imagine supplementing with something like (for instance) a Haskell library that lets you generate JS code for interfacing with the back-end in a provably correct fashion, and plugging that into the UI code.