That's not true. There are plenty of cases where certain pieces of software is cordoned off and/or non-critical that would not affect the rest of your stack if they fail.

If you properly do validation at runtime this can be true, but it's a manual process that's not verified by Typescript.

To your point, I do think it depends on the team and their ability to make good judgment calls.

But type safety is a spectrum anyway. One could say that not having dependent types is like having a swimming pool without a lifeguard.

Should every swimming pool in the world have a lifeguard? Probably not.

Lifeguards are expensive. Basic typing is damn near free. More languages should adopt dependent typing, but for the moment there are languages that lack it and offer enough advantages to make up for that. I don't think you can say the same thing for languages without a true type system (one in which unsoundness is the exception rather than the rule) - there are too many good alternatives for it to be worth compromising on that.

It makes it really easy to add type safety to parts of a legacy project as you go along; for new projects you can enforce type safety with a linter or stricter compiler settings.

A more accurate remix of this analogy (for the TypeScript case) is that it is like building a wall around the part of the pool that you actually swim in, and allowing that folks can pee all they want as long as it is outside of the boundary you built.

Does Typescript actually add runtime checks, even for e.g. container types? I'd be very surprised if it did, because that would mean a lot of overhead.

It does not.

Would you say the same about incomplete testing?