I've often speculated that strong typing only seems like a win to the kind of developer who makes a lot of type errors, and a waste of time to those who don't (which doesn't mean they don't make other errors, of course).
Or just to the developer that likes to offload that cognitive load to their tools.
Why hold that in my head when the IDE can keep track of it for me? Why memorize every single attribute name when the IDE can autocomplete it for me? etc.
Instead keeping track of the type annotation in your head, and then also keeping track of the rest of the stuff in your head too.
If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result.
Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster.
"Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types.
My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript.
Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"
Yeah, they're optional, but if you don't write them, there's no point in using TypeScript in the first place.
2) If the types can be inferred, that should just happen. No objection there. But this piece is specifically about "adding (manually-authored) type annotations to JavaScript"