I've introduce TypeScript to multiple teams already, and if the transitions were not frictionless, they were always extremely fruitful in the end.
And I can guarantee using a more sound (and more complex) type system like Elm or Rust would have never succeeded, because people using high-level languages don't want to know about low-level CPU/memory details, they just need to build things and have something that is "fast-enough" (and safe-enough, if possible).
Both Rust and Elm have a much simpler type system than TS.
Well, for Rust it can maybe be argued to have its complexities but Elm is dead simple. In fact the most common criticism of Elm is that it it lacks more complex features that people from the Haskell world are used to.
Allowing for the gradual typing of a dynamic language like JS is extremely challenging requiring stuff like structural typing which is not at all common in most mainstream programming languages. I don't thing there are many mainstream languages that have a more complex type system.
The value TS offers is ease of gradual adoption and access to the huge JS-ecosystem and for that you absolutely pay a price in complexity. It is absolutely trivial to design a language with a much simpler, sound type system that offers higher productivity and a smaller learning curve than TS but that wouldn't have much value for most people as the access to the JS stuff and gradual adoption.
I both agree and disagree with this. I think if you're coming from a statically typed language, and you're familiar with features in those language - Typescript is a very complex type system, where it can often be difficult or frustrating to express common paradigms.
That said... if you're coming from something like Ruby/JS, typescript has a pretty simple path to convert your existing code, and it doesn't get too fussy about letting you punt on the problem for a bit (start with very loose rules and lots of "any" - get more strict over time).
There is a confusion on terminology though. You are arguing about ease of use which is a different measure from complexity. That might have caused a misunderstanding.
Complexity is an objective measure while ease of use is subjective and based on your previous experience. For example the language Brainfuck is very simple (conceptually) but very difficult to use for most humans.
TS is objectively complex but also easier to use for Ruby/JS devs as you wrote.