I use TS daily and I think this sort of argument doesn't give TS the credit it deserves.

Sure, you _could_ use it to check that you aren't making obvious errors like this (but this seems constrained to the "convince me that it's worth it" level of functionality, as it is just a nice-to-have for an existing working pattern).

Where TS shines for me is that it ENABLES new ways of "ad-hoc" coding where it's no longer risky to just create "convenience objects" to represent state when prototyping/refactoring, since you can avoid specifying concrete required types across a load of middle-man code and compose types at each level. This enables the pattern of splatting (composition over inheritance) a bunch of inputs to your data together, and then routing them to the points where they are needed. This scales nicely when you introduce monadic fun (processing some data with children, or something delay-loaded) since your type constraints basically write the boilerplate for you (I'm sure co-pilot will make this even more so in the far future).

There's also the fact that your can have your back-end APIs strongly typed on the front-end via something like GQL or Swagger, and this saves a TON of time for API discoverability.