It doesn't have to be like this. This is the point where identity portability comes into play. If the identity belongs to the user and they carry to different servers, the user is independent from the provider.
In the case of email/irc/matrix, as long as you own the domain name, you can change the service provider whenever you want.
There are two separate things here, identity portability and data portability. If your identity is portable (say a key pair) but the service hosting the data goes down and you don't have a backup or there's no way to import the data to a new provider then you've got a problem. Similarly, if the service goes down and you do have a backup of your data and a way to import it to a new provider but your identity isn't portable (perhaps it was user@domain and you don't own the domain) you also have a problem in that case but it's a different problem.
And neither data nor identity is the same as account, at least the way I was using the words.
No, it still gets to be hosted by someone else. And it is not just because I am using a custom domain that it requires a separate server. "Shared hosting" has been a thing for web and email forever, and there is nothing stopping* a matrix or an activitypub server to process requests for different users on different domains.
> tying your identity to ICANN DNS.
Not necessarily. If you see the linked conversation I had with Alex, it was about using Ethereum ENS. It could also be something based on OpenID. The important thing is that the actorid in activitypub can be anything that can be authenticated by the server, it doesn't have to be only the internal username.
* there is a current limitation on matrix synapse (where the homeserver can serve only one domain), I don't see anything on the protocol that forbids the implementation of a multi-tenant server. Perhaps it is not a top priority because such a server would incentivize big hosting companies to offer it as a service and possibly re-centralize it.