The visibility modifiers are optional, only checked at compile time, and quite frankly solve a problem that JS developers have been solving badly for a decade now. From "gentlemen's privates" (ie, if it starts with an underscore please don't touch it or rely on it!), to closures to CommonJS modules, all ridiculous contraptions essentially designed to give you some sense of privacy in the language.
TypeScript doesn't have enums. Instead it allows you to restrict a string to a finite set of values. Which basically boils down to JavaScript "enums" with a dash of static typing thrown in.
I have no doubt TypeScript tends to attract C# and Java developers. But that doesn't take away from the fact that TypeScript is a proper superset of JavaScript, it doesn't force you into a rigid class system at all (structural typing for the win), and really, truly is "JavaScript with types".
TS sure as hell has something called "enum", which is NOT the same as their string literal types (those are good).
I disagree about the privates: closures are perfectly good functional ways of handling them, and if you didn't want that, we have symbols now to do it for "real". And privates aren't terrible. Protected however are OOP bullshit.
Though my primary point isn't in how its features are implemented: it's how they're advertised. That, to me, is what makes TypeScript "a C# for the web". It's implementation isn't terrible, especially if you stick to the "good parts". However, the "good parts" they advertise/encourages are javascript "bad parts.
I honestly think "protected" is not worth fussing over. Not to mention JS becomes more classically oriented every day. I predict ES2018 adds "protected" :)
Anyway I honestly don't have much opinion on how they are marketing TS. The language itself is well done and that's all I really care about.
Or rather, TypeScript isn't bad, but the way it is documented might convince people to do bad things. It took forever to get "the good parts" of JavaScript in people's head, and that doc is really a step backward.
If you just use TypeScript's types and run away with that though, it's pretty good. If you start using classes all over, rely on private/protected/public like crazy to make complicated domain models, abuse decorators to hell, enums, etc... then it's C# for the web.
It doesn't have to be used that way, but those features made available and having a high focus in the official doc is causing a lot of issues when people coming from Java/C# hop in a TypeScript code base.
We don't use TS here, but when we hire people who come from TS companies, we have to tie them down for them not to start writing C#-like code, and remind them that it's structural typing, etc.