I can't help it but disagree with the author.
His example shouldn't make someone think "god, I wish I didn't have to specify the type here", but rather "wait, there's a problem here. There's way too many concepts in a single line of code, I should probably refactor that to make it clearer". Having to specify the type is what should help the developer come to the realization that something needs to be more modular, so the people reading the code in the future (including him/herself in a week from now) will have a easier time understanding what's going on.
Overall, I feel like there's a common thinking these days that most of software cost is in the time spent to write it and thus we should use any means necessary to reduce that time. type inference everywhere makes it so that just reading a source code prevents you from knowing the type of anything without learning first the whole API by heart. And it's reaching the top when you define a function using "fn" in rust (there might be another explanation than saving keystrokes, but I can 't think of any), or "go fmt" instead of "go format".
IMO, the truth is that while a code has been written exactly once in its current form, it's being read hundreds or thousands of times. For learning, debugging, fixing, improving or adding performances. It doesn't matter. And when you have to read the code to understand the concepts behind it, you're just wasting brain cycles.
Yes, typing types everywhere is a complete pain in the neck. But reading and modifying code without anything has always felt 100 times worse to me
