TypeScript Features to Avoid

As long as it is supported — and at least esbuild does, who cares (as a user). Should I start avoiding every JS feature that is hard to implement in alternative JS runtimes?

I most strongly disagree with the recommendation against enums. Realistically, you will probably never run into a compiler bug from enum emit; maybe something like this might happen with a very complicated runtime feature, but enum emit is dead-simple and hard to get wrong (at least if your toolchain has any tests at all, which it presumably should). And they're generally convenient and fill a useful niche, especially numeric enums with implicitly assigned values. (I'm also curious what the article's authors think of const enums.)

Namespaces have been soft-deprecated, modules are pretty much just better, and so I quite agree that you shouldn't use them, though I'm not sure the risk of compiler bugs is the most compelling argument against. (It is more compelling than with enums, since the required code transformations are much less trivial.)

Decorators, especially with metadata, facilitate lots of useful things that otherwise just aren't possible in TypeScript. It's also the case (though the authors seem unaware of this) that they will never be standardized in the current form that TypeScript has them, because they were based on an earlier version of the design that has since been pretty explicitly rejected. The risk isn't that decorators are never standardized; if that happens then TypeScript will just keep the current design forever and things will be mostly fine. The risk is that they get standardized in an incompatible form and then you have an interesting migration ahead of you. TC39 won't do this lightly, but no one knows exactly what the future holds. So it is a tradeoff to think carefully about, though in the end reasonable people will disagree.

# vs. private is mostly a matter of style/taste, with two exceptions. First, if you have any code on your page that you don't trust not to be doing weird things, strongly consider #, since it provides protection against corruption of internal state. Second, if you have to support older browsers that don't support #, then don't use it; the compiler can downlevel it, but only at significant code-size and performance cost that you don't want to pay (and debugging it in the browser will also be annoying).

Do the authors also disfavor parameter properties? Those also require emit beyond just stripping types, but are super-convenient and useful and don't really conceptually complicate things.

Incidentally, the feature at the top of my own list of "TypeScript features to avoid" (other than namespaces and other soft-deprecated features) is something entirely different: conditional types. Most other advanced type-system features behave reasonably predictably most of the time, but conditional types are very demanding of maintainers' knowledge of fiddly type-system details. I'm not saying it's never worth it (and in particular the built-in utility types are usually fine even though they're conditional under the hood), but whenever possible I try to reach for something else.