Agreed and I think the reason for this confusion is because string types generally aren't considered a complicated feature of typescript.

Nor is it unique to it. I.e. elexir does the same through pattern matching and it works even better as far as I'm concerned.

It's more about the features that enable extended type inference and modifying these inferred types on-the-fly.

Easy to understand type modifiers like Omit<>, Partial<> etc are fine, but if you lean into that you can create pretty hard to understand typing logic. Especially if you're diving into annotations for code generation

The pattern I'm most familiar with is using type constructors:

   type Shape = Square Int | Circle Int

and then pattern matching:

   print (Square size) = ..
   print (Circle radius) = ...

In Typescript this would be something like:

   type Shape = { type: 'square', size: number } | { type: 'circle', radius: number }

And string matching for type narrowing:

   function print(shape: Shape) {
     if (shape.type === 'square) {
       ...
     } else if (shape.type === 'square) {
      ...
     }
   }

The TypeScript approach is comparatively weird and verbose but also pretty clever since it doesn't require any change to the core language.

It also have some pitfalls, e.g. you can write:

  print({type: 'square', size: 10});

But you cant write:

  const x = {type: 'square', size: 10};
  print(x); <-- type error

You have to write:

  const x = {type: 'square' as const, size: 10};
  print(x);

Things like this just complicates the type system and type inference.