TS/Flow don't quite lose types "whenever" partial application or currying is involved, it's a bit more subtle than that and in many cases it works fine. But especially when using generics with currying you often have to rewrite in more verbose ways (or structure the functions in a particular way) to make the types check through.
No, that is exactly correct. The brunt of the argument applies to most popular languages- Java, Python, Ruby, and what have you- although the specifics vary.
You can get exhaustiveness checking in some cases in TS by adding a default statement to a switch and assigning the value to type 'never'. This is a bit cumbersome, of course, and the fact that it's opt in partly defeats the purpose. You typically want to check exhaustivity to get more safety, but there the safety only comes if you add it in manually so everywhere you forget you lose safety.
Naming closures or functions absolutely is a good substitute for a large class of comments. When you write a comment as a function name, that comment gets maintained when the code changes. It also encourages modularizing your code- often when you write a comment it's a sign that your code is trying to operate conceptually on more than one level and it would be more understandable to separate those levels.
I wouldn't say comments are an antipattern but they are a code smell and should be used sparingly and only where the same explanation can't be given through function/variable naming or refactoring.
Part of the issue is that legally in the U.S. a) privacy violations are usually punishable by law only if a specific non-privacy harm comes of it and b) privacy is treated as an individual right and not a societal good. If a company gets hacked and loses your credit card and bank information afaik it's punishable only if someone actually fraudulently uses the information. It's up to individuals to jointly complain about specific damages to effect changes, and for any given individual there's little incentive to make your own life difficult for vague potential benefits. Also in most cases the individual harm is quite small, even if in aggregate or viewed as a societal harm there is huge damage.
Which specific ones, for example? "Every one" could cover a lot of ground and doesn't have much information content. It's doubtful you have experience in every one, and it would be useful to know which specific ones have been tried and seem better.
This is what makes me wonder, is there actually a steep age bias and drop-off of older developers or are we just living a demographics change? I'm guessing there are far more developers today than ten or twenty years ago. When those developers age, will we see a more natural age distribution?