Point being that if you get a valid TLS connection from a client cert, and then you get another valid connection from the same cert tomorrow, you can be very certain that the entity connecting is either the same software environment that connected earlier, or an attacker that has compromised it. You can be cryptographically certain that it is not an attacker that hasn't effected a full compromise of your client.
And there's value there, if you're a server. It's why XMPP wants federated servers to authenticate themselves with certificates in the first place.
> This is basically how Let's Encrypt / ACME accounts work
That's how they're implemented. How they "work" is a trivial pushbutton thing as documented by a well-known and trusted provider who cares deeply about simple user experience.
"Just self-sign a cert" is very much not the story XMPP wants their federated server operators to deal with.
I can't believe this was downvoted. Seriously a Certificate is binding a public key and the attributes (mainly the identity). If you don't need to use the attributes, you don't need a certificate!
And there's value there, if you're a server. It's why XMPP wants federated servers to authenticate themselves with certificates in the first place.