Maybe I don't use a mouse to understand _my_ code. Maybe I use it to understand the code of someone who left the company years before I was hired. I think the place that TS really shines is in helping people get up to speed quickly on code they had nothing to do with writing (spoiler, an article somewhere in my queue is "that time Typescript saved my project").
If you consider comments to be code, then you're already writing at least 2x the code anyway. The thing TS gives you is it takes a lot of the conflict out of it when people inevitably don't follow someone's rules. And of course it gives you better tooling (wah wah wah, right?).
Generics don't have to be agonizingly cryptic, and they're best when they're used in ways that people don't need to think about them, such as
function doSomething<T>(someArg: T) : T[]{
//function here returns an array of the same type that the argument was
}Then when you call
doSomething('foo'), TS picks up automatically you'll get back an array of strings.
Javascript is an amazingly flexible language, and generics allow you to express that flexibility while keeping strong types. The problem is that many, if not most, developers who use it use it because they're made to use it and not because they particularly care about the benefits, and in that case they don't use it well. But this can be said of a lot of technologies--if you put them in the hands of developers who just want to bang out code and go home, you're not going to get great results.
In addition, it takes around a year to get to where you have enough experience to start to get those benefits--so you're right that on a lot of projects you get no benefits, either because of attrition before that year point or because the project isn't long enough for the benefits to be felt.
The irony is that the more experience you have with TS, the fewer types you write, because you learn that TS is actually pretty good at reading the code and inferring types, which then are enforced later (and available to the tooling wah wah).
The problem in too much of our industry is that people make technical decisions based on blog posts by people who have more influence than their skill level justifies rather than understanding the basics. But then one way to get that influence is to tell people that the basics aren't important and you'll be just fine if you can slap something together by the end of the sprint.
