Not even close.
While TLS technically supports client-side certs, all extant implementations of it are unbearably clunky to use, completely ignored by all vendors. Meanwhile the tooling around SSH keys (like ssh-agent) is seamlessly integrated with your OS and works so well that it's easy to forget it even exists.
Browser vendors completely dropped the ball on this; they dropped it so hard it continues to hurt even after all these years.
I've yet to get to the point of moving to "modern ssh" (ed25519 key/certs, chacha20-poly1305 encryption etc) - with certificate only. Because keys are *so' convenient. But they're also, while better than passwords, pretty bad: No expiry, no easy rotation, no easy revocation.
I will say this though: it should be quite feasible to move to modern ssh, banning keys and passwords (other than perhaps as a second factor), and moving to certs only. But clearly deployment of reasonable ssh setups are lacking behind the technological improvements.
I hope things have gotten better now, but five years ago I ran into this in spades. Pulling teeth both to implement and then to explain. Especially if it's from a cert chain, and doubly so if you want to only trust certain from your CA.
And I think across the whole stack we ended up with three TLS stacks, and some HSM hardware. So I got to figure out trust stores multiple times.
I should have run screaming, but I stayed at that job an extra five months just to make sure that everyone really understood the mutual certificate auth code at a practical level. There's gotta be a better way.
I really think we need a hybrid system that is more like PGP, where you have a key chain and get advisary info from your peer group about the veracity of a CA Signed cert.