I think that implementing Enum in a C-like style with numbers is fine, because an Enum (similar to a Symbol) is usually used to declare a value that is uniquely identifiable on development time. How the machine represents that value on run time doesn't really concern the developer.

But what we developer sometimes want (because we're all lazy and still want to have all the benefits!), is to use the Enum as an API or with an API that does not share that Enum with us, even though the API is essentially an Enum because the valid value of a property only is foo and bar.

I guess this is the reason why some languages have string based Enums :)

How TypeScript handles Enums

If you look at the transpiled JavaScript you can see that TypeScript just uses a plain JavaScript Object to implement an Enum. For example:

enum Color {
    Red,
    Green,
    Blue
}

will be transpiled to:

{
  0: "Red",
  1: "Green",
  2: "Blue",
  Blue: 2,
  Green: 1,
  Red: 0
}

This means you can access the string value like Color[Color.Red]. You will still have code completion and you do not have to specify the values twice. But you can not just do Object.keys(Color) to iterate over the Enum, because the values exist "twice" on the object.

Why didn't they make enums string based

To be clear Enums are both number and string based in that direct access is number and reverse map is string (more on this).

Meeting your requirement

You key reason for ruling out raw enums is

so I can't simply read from JSONs which are string based...

You will experience the same thing e.g. when reading Dates cause JSON has no date data type. You would new Date("someServerDateTime") to convert these.

You would use the same strategy to go from server side enum (string) to TS enum (number). Easy done thanks to the reverse lookup MyEnum["someServerString"]

Hydration

This process of converting server side data to client side active data is sometimes called Hydration. My favorite lib for this at the moment is https://github.com/pleerock/class-transformer

I personally handle this stuff myself at the server access level i.e. hand write an API that makes the XHR + does the serialization.

At my last job we automated this with code generation that did even more than that (supported common validation patterns between server and client code).