A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs.
Can be, indeed, but was not in existing implementations, to my knowledge. My point (perhaps I was more clear in my followup comment) was that we shouldn't shed too many tears given the actual implementations did not provide the promised security gains. Were they stepping stones? Maybe. But they didn't (yet) deliver.
> A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs.
Yes, but, bizarrely, IPs actually provide more security against some threats, as I noted. I don't think this is because IPs are a great security measure--they're not!--but because token binding as implemented was pretty weak.
You're comparing a fundamentally bad design that had decades of "refinement" but cannot go further to a first stab at a good idea that has many ways to improve (storing keys on hardware tokens or TPMs, preforming signing on a TEE). Storing the keys on a hardware token might even make sessions portable without having to enter secrets into an untrusted machine.
I think token binding itself had some design flaws that made it hard to realize these improvements, but that's not to say that I think IP signals are better (or obviate) cryptographic replacements for bearer tokens—I don't think that. I just think it's an irony of token binding's design that the design suggested an implementation which in practice provided less value than IP binding.