Browserify can help with breaking your code down into smaller reusable modules for the client side and node you want to make your modules as small as possible? From the sounds of it you fell into the one big huge application that does everything problem instead of breaking it up. The same issues would have happen if you would have done that in any other language.
You can hide variables through closures and sorry not a fan of getters and setters, I feel they are a anti-pattern (http://www.yegor256.com/2014/09/16/getters-and-setters-are-e...).
The one thing that would be nice would be knowing where your code is called. Though if you are using NPM and Browserify then that can be easier as well. I agree though that the tools are not as nice as Visual Studios find callers and the intellisense isn't that good ether but I am willing to trade them for the flexibility of not having to declare types and the simplicity of not having to work around types with generics, interfaces, and casting.
We have unit tests (fewer on the client than server though), CI that runs integration tests, automated UI tests and other stuff - but that's all much slower than "VS tells me that my code's broken so I should fix it before starting to debug". We'll catch bugs with TS or JS, it's just how long it takes to catch them that's the issue.
Same with reviews and training - we have both, but our team isn't big enough to have people dedicated to each area. We mostly hire C# devs, for better or worse, and want them to be as productive per hour as possible. Having it harder to shoot yourself in the foot means fewer feet shot over time, regardless of the team and their skillset.
Getters/setters was an unclear use of term "properties" on my behalf (which actually referred mostly exclusively to methods). Regardless of my personal opinions on getter/setter methods/closures etc, we have established patterns that will take a while to change. The problem is there, and so tooling that helps reduce what breaks when we make changes is a big plus. We don't have a robust message bus in the application, so there's a lot of crosstalk (that's a refactoring area).
We're about 10% new code, 90% refactoring and updating (though that's a guess, I haven't looked at the stats lately). For us, JS is more painful to maintain than C#. From what we've seen, TypeScript will give us significant benefits on that 90%.