I disagree with most of this post, but I respect that it's the author's experience. Kudos to the author for including a section adressing comments. Basically I agree with all of the comments. =)
My experience is that I've pushed for and got the team to want type annotations in our code. Admittedly it had a bit of a threshold initially, but overall it's been a great experience. I have repeatedly had the checker find issues much faster, both in terms of how quickly mypy runs and in terms of how early the issue is flagger, than we would have without the annotations.
The one major thing I agree with the author is that in this transitional period it's frustrating to know that separate typing packages may be out of sync with the package they type. But that's transitional and has been a surprisingly rare problem.
Two decades ago I dismissed static typing as a "performance hack", because that's how the horrible weak static typing system worked in C, but the way it works in languages these days, in particular in TypeScript and Python, in particular when it's about structural subtyping rather than nominal subtyping, I find it genuinely helpful.
It will be even better any year now when we're able to upgrade to Python 3.8 (we still have transitive dependencies that break on Python > 3.7, I check in on them periodically to see if the time has come). Protocols yay! Python on par with TypeScript!
Probably the sticking point here that made it a miserable experience for the author was: 1. Broken CI. That's a bug that must be fixed. Don't use executable documentation if you're not going to execute it. I agree this make annotations more harmful than helpful. Don't merge broken annotations, just like you don't merge broken tests. It's misleading.
2. Worry that the checker and the runtime and the language would be out of sync. They haven't been in my experience, and it seems like they hadn't been in the author's experience either. Maybe working with the tools more would have provided more confidence, but (1) got in the way of that.
3. Worry about bugs in the implementation of the checker. Including it in the compiler wouldn't really fix that. Bugs should be fixed, regardless where they are.
What we have run into has been some conflicts between flake8 and mypy, but we found workarounds to make both happy and later flake8 got fixed to keep up with the language and the type system.
Basically with Dropbox doing 100% type coverage and Guido working at Dropbox any issues that may have existed before were removed before Guido left in 2019 and with that kind of everyday use we have no reason to expect them to come back without anybody noticing.