You can just read the thread linked from that bug.
* Endpoint compromise is (and has been for awhile) outside of Chrome's threat model. This comes up a lot. The simple way to understand it is that the Chromium team refuses to get into an arms race with malware developers to protect secrets from code running at the same (or greater) privilege level as Chromium itself.†
* Token Binding is a particularly complicated feature, so the effort/reward calculation was unfriendly.
* Nobody was using it (on the clientside, with extension developers or people enabling the feature flag, or on the serverside, with major sites actually enabling it).
* Token Binding alters the semantics for cookies, which the rest of the development ecosystem generally assumes to be simple bearer tokens, which has the effect of breaking features and extensions that depend on those semantics. Again, if the reward were higher, this wouldn't have been a dealbreaker.
Token binding is, I think, pretty much a dead letter at this point.
† FWIW: I think this is a super-reasonable position for them to take.
Token Binding protects against more than just endpoint compromise. It protects against users who copy and paste their cookies somewhere (possibly due to phishing, or due to just debugging why a request is failing). It protects against webservers that log cookies, and those logs leak or are disclosed wider than they should be. It sometimes provides protection against https MITM (via stolen or mississued https certs/private keys). It provides protection against other types of cookie leakage, for example Cloudbleed.
I'm just recapping the thread. I don't have a strong position on token binding (we wrote about it a tiny bit in our inter-services authentication post).
Chrome is encrypting the cookies at rest so there is some protection of the secrets. I wish Chrome would allow a master password (per profile) to further protect the stored passwords and cookies.
