Well, as others have said: Hitting exactly 80% is pretty much impossible. And we've established that hitting more than 80% produces languages that are often bad, in some way or another.
So, logically it follows: aim for less than 80%. You can always add things; you can't take things away.
I've noticed this as well. It also attracts a lot of criticism. People are really insistent that a language should be perfect in exactly one area and terrible in others. They tend to support this kind of thinking with arguments about how you should pick the right tool for the application, as though most applications only care about one criteria or another (and need a language that trades everything for that one criteria).
That said, I think Rust does an impressive job at squeezing efficiency out of these tradeoffs. Sure, it trades off some developer productivity for extreme performance and safety, but its developer productivity story is still markedly better than other systems languages (and probably on par with some of the more cumbersome managed languages). Similarly, the tooling story is pretty great while every other systems language has pretty awful tooling (especially build systems). Moreover, Rust is getting better at a remarkable pace. I don't think it will ever close some of these gaps, but I think it will get close enough to pose a real threat.