If Typescript can deliver 90% less errors with the same team, saying "Must be a bad developer" is a useless comment.

If TypeScript let's that developer make good code, then the variable is JavaScript.

That's the great thing about Type systems. It doesn't matter if the development team is amazing or not. Typescript still makes huge classes of errors impossible. It also speeds up development due to superior IDE support.

I've only used TS on the frontend, but I had the same opinion as you until I dug into a couple of TS projects. I don't know if I've ever caused a JS production bug that was a type error at its core, but I've had plenty of bugs like that in development. TS lets me cut out those little dev cycles where I'll write some code, rebuild the app, then see an obvious error in the JS console when I run the app. That adds up to a lot of wasted time over a week of coding. Smart autocomplete and smart variable renaming is also really nice, and I have way more confidence refactoring a TS project than a JS one. I think using TS does result in fewer production bugs, but the big win for me has been having fewer development bugs.

Types are good for more than just "int instead of string". What you consider a type related error is likely not the full set of errors a type system can prevent.

Aside from the other responses you are getting, consider that the "90% less errors" doesn't actually tell you anything about the overall quality of either codebase. It could be a million lines of JS/TS with 10 errors found in the JS vs 1 in the TS. That would be a 90% reduction, but 10 errors in a large codebase would still be pretty excellent.

A great carpenter can hammer a nail with a screwdriver, but that doesn't mean it's a good idea.

When the tools help you, a good developer can focus on making better things rather than not making mistakes.

Tests are also a red flag for the same reason. Just suck less, I always say!