As somebody that used to use them for a while: The ergonomics of TLS client authentication in the browser were abysmal. And that's to say nothing about the privacy consequences.
iirc managing them was buried super-deep in the browser settings (just like managing resident keys, browsers don’t even do that), but enrollment was fairly simple from a user PoV - submit a form and the server sent back the certificate, iirc you had to confirm a scarily worded dialog (or maybe import it manually? Not sure). Login was smooth if I remember it - just a pop-up if you want to use the installed certificate. Privacy should be fine with TLS 1.3 but would’ve been nonexistent with the contemporary SSL/TLS versions of course.
That's unfortunately not how it works. TLS sits at the transport layer, so it's not possible for a website to use these certificates for a "login-like flow". The site doesn't get to present to the user why and to whom they are authenticating, since transport layer authentication has to happen before HTTP even gets a single request in.
There is also no "logout" button. It shares these UX problem with HTTP "basic authentication" (even though that's technically an application layer protocol).
On top of that, TLS is these days often terminated by a load balance or even a completely separate entity like Cloudflare. Not sure if you can configure these to request client certificates at all; even if you can, it makes things pretty awkward if you want to have closer control of the authentication flow.
> Privacy should be fine with TLS 1.3
It's not fine at all. Any HTTP server can request your client certificate, and most users would probably not think twice before clicking "authenticate", which then reveals their long-time stable certificate and public key to a potentially malicious server.
Compare that with WebAuthN, which makes it intentionally impossible to accidentally present the certificate for a.com at b.com.
