"Using" a programming language is 99% reading and understanding code and 1% writing code. I only control the 1% i write and not the 99% I read. You can't know everything but you need to know enough to understand most of the code you read. If a feature becomes popular among others, then you need to understand it, even if you never use it yourself.
It's never this simple. You have to decide what subset to use, understand how that subset could interact with the avoided language features, have a strong team culture that can agree on the subset and have the discipline to commit, understand how new language features affect that commitment, etc. In addition to needing to read and interact with other libraries that probably use it anyway.
The team aspect alone is a deal breaker for me--when you have a technology that attracts people who are intrinsically interested in the technology, good luck trying to get them to avoid certain parts of it. That's a losing battle.
You can write custom pints if you're willing to build a custom toolchain (shouldn't be too terrible to rebuild it once a release)
That said, GATs fix a real pain point not actually shown in the article. And that's for impl return types in trait methods. You can have return impl types in normal functions, and even associated methods, just not in trait methods. I think the term for this is existential types. And they occur a lot with async. So async in traits is a real pain point this feature fixes.
