Nice article/writeup. I find that if you are permitted to make heavy refactoring more of a norm, it's incredibly beneficial. Outside of that, I'd rather not have it in the first place. I tend to be pretty stringent in terms of project structure (discovery first), which tends to lessen the need. It takes a lot of time to add all the typing information. Also, as the article mentions adding to certain types of JS functions is painful at best. Not to mention default linting is very strict and makes it even more difficult to bypass in practice.
As to JS tooling (babel specifically), odds are if you're using newer features, or supporting older browsers (IE), you'll need babel anyway (and likely multiple builds/targets). async/await and conditional continuation operator (?.) are two of the big ones the former for old browsers, the latter just plain not in TS.
NOTE: it might be worth it to enable the types for better VS Code for outside libraries, which can improve things. And/Or disabling all required usage for linting purposes, which will make it easier to bypass and opt in where really needed.
I'm firmly in the rather not have it category, but I can see the potential value.
The article uses a data driven approach but some of the data is purely subjective from a developer who has worked with it for a year with an understanding of the language features that according to himself leaves a lot to be learned.
I've used it a lot longer than a year. I have more than one year of full time exposure, meaning using it most of my day every day.
I have been using it on and off part time for close to six years, and I have led multiple large scale TypeScript app projects, some as tech lead, and some in C-level executive role which exposed me much more to the cost analysis perspective.
I do have a lot more to learn about TypeScript, but I also know quite a bit more about it than many who would consider themselves fluent.