Parameter properties are I think still used quite heavily in Angular, but I don't see them much elsewhere. Again, they're a very old feature, and they don't play well with newer developments in the language (such as native private attributes), so it doesn't seem like much of a problem to avoid them as well.
The other big TS-only feature is old-style decorators, but that shows the danger of relying too much on this TS-based syntax sugar. Decorators have gone through several revisions, and the version that Typescript implemented is long dead. But a number of codebases are still stuck using this legacy system because it's not compatible with the newer versions of decorators that will (eventually, hopefully) be implemented in browsers. The legacy system is still maintained, I believe, and you can still keep on using it, but you'll not get the benefits of using the same system as the wider Javascript ecosystem, and you'll not get the benefits of having the syntax be native to browsers, when that happens.
In general, Typescript works best when you use it as simply a type annotation syntax for Javascript, and not as an additional layer of sugar on top of that. And clearly the Typescript developers see things similarly, because they've stopped implementing sugar-like features and have committed to only implementing the stuff that will also be implemented as new features in Javascript.
Parameter properties and namespaces, on the other hand, are kind of wonky TS specific features that nobody expects to be there unless they specifically find them in the docs. Parameter properties offer a little bit of conciseness but don't fill a pressing need. Namespaces solve a problem that just doesn't actually come up that often, and few devs are going to go actively looking for them. Even the example code on typescriptlang.org doesn't show a very compelling case; they show "Validation" used as a namespace for classes that are already namespaced the low tech way by having "Validator" in their names. (Which isn't to say that the feature isn't ever useful; it's just that cases where someone would actually seek it out are niche.)
All of that is to say that sure, enums are just one of a handful of features that will break in runtimes that simply strip out types, but they're also the main feature that's likely to trip people up.
> maybe in the future JS runtimes might be able to strip away types for you without a build-step.
You can't backpedal from that to "speaking about the specification". It's not future JS runtimes. It's a thing you can take advantage of right now.
Not just the future. Node shipped this with an "experimental flag" in the last LTS and in Current it works without the flag (will ship in the next LTS without a flag). Deno has done something like this for years now, and Bun for nearly as long. The remaining question is if/when Browser support might also exist, which for now remains at Stage 1 discussions with the technical committee (TC-39).
Seems weird to me to decide you're OK with the build step and all the other complexity TS adds, but using enums is too much, because maybe in the future JS runtimes might be able to strip away types for you without a build-step.
But we all have different constraints and use cases, I suppose it does make sense for what you're building.