It's useful as a tool for communication and simplification. Ignoring those features, typescript is just javascript with type annotations, which makes understanding how something works easier. I've worked with a number of developers who have been confused about what's a typescript feature, and what's a javascript feature, because this boundary feels blurred (particularly when working with modern ESNext syntax that might not be implemented in browsers but is understood by typescript). Being able to say clearly: everything after a colon (and some other places) is typescript, everything else is javascript is a great way of helping people understand what's going on.

In terms of the tradeoff, I rarely, if ever, use those features in the first place. For enums, I'd rather just use string literal types, which are slightly easier to write and compose, potentially assigning them to variable names if I think that's clearer for a given use-case. For constructor properties, they don't work for private properties which is the most common property I'm writing, so I don't really see the value.

The two other features that are disabled are namespaces and modules that contain code, and `import ... =`, both of which have clearer JS alternatives.

FWIW, you can enable those features in node, although that's still behind an experimental flag. It's marginally slower (because the translation is slightly more complex than replacing types with whitespace) and it requires sourcemaps under the hood, but if you really want those features you can have them. Or you can use an alternate runtime that supports them out of the box (Deno, Bun). But even then, I think they make teaching and understanding the language more complicated and I wouldn't personally recommend them. (Assuming someone might listen to the personal recommendation of a random HN comment!)