Refactoring and maintaining consistency are the two big problems we have with Javascript. It's easy enough to write javascript that works and does what we need it to do. The challenges come in when you start having separate components that need to interoperate.
eshint/jshint etc take you only so far (preventing you from dumping things into the global scope, avoiding typos). AMD etc can take you a bit further with async loading, and give a better [more consistent] pattern for exporting things than saying to devs "just put your stuff in an IIFE". FB Flow looks helpful, but it's trying to solve a difficult problem, and unfortunately doesn't work so well with our code thanks to ONE bad decision made a long time ago to rely on declaration hoisting ("unreachable code" :( ).
Anyways, knowing that your code isn't going to work before you start spinning up the application saves a lot of time.
Knowing that you can rename a method/function and have no undefined errors come out of it is great. Being able to look up usages of a method across the entire codebase is also useful. Eventually if Microsoft decide to spend resources on it, TypeScript might get CodeLens (which is on its own all manner of cool+useful).
Having class syntax means that you don't need to worry about external consumers accessing properties that they shouldn't be (+gets rid of silly conventions like underscore private members/methods).
JS is a great language, and it's powerful, but when you're writing large quantities of stuff, sometimes you need structure. Particularly when it's a large team and there are people of wildly varying experience, ranging from near-zero JS experience to people who have used it for a decade or more.