The warning fatigue problem is still there - and we're talking about a warning for 4-10% of all connections according to the study. Plus, as you pointed out, this would only help against the average sysadmin; if we assume an advanced sysadmin convinced to not disclose their snooping or an actual attacker, replacing the browser binary would not be a huge obstacle. In that sense, it might even add a false sense of security. It's a bit like the state of certificate revocation - it works most of the time, just not when you actually need it.
This figure of 4-10% of connections is meaningless here, either you're intercepted or you're not. The warning would only matter for websites that bother to implement certificate pinning.
I don't really know how widespread key pinning is but if it's reserved to the more sensitive websites (banking, e-commerce etc...) it might make sense to at least issue a warning.
> This figure of 4-10% of connections is meaningless here, either you're intercepted or you're not. The warning would only matter for websites that bother to implement certificate pinning.
Most Google properties use key pinning in some form (though AFAIK through static pins rather than HTTP headers). I would suspect that most users in that group would see such a warning at least daily.
> I don't really know how widespread key pinning is [...]
"Visitors may be presented with a warning if they're behind a middlebox and you deploy HPKP" would probably be a good way to slow down HPKP deployment even further.
