It's DNS-like identities that resolve to a DID (with the DID as the canonical identifier), and from a DID you can update the DNS-like identity to something else, or point to a new Data Repository location. It looks confusing at first especially when it provides an example username like 'alice.example.com', when it doesn't actually mean a subdomain of 'alice.example.com', instead that it's just 'alice' namespaced under 'example.com', which as stated, can be renamed/moved:
https://atproto.com/specs/did-plc#example
Then I'm sure there's the confusion of "well, what if you have just a DID, then how do you get the original DNS-style identifier again?", whereas I assume there wouldn't be such a situation, as any new posts or content would include both the DID and DNS-like identifier. The DID is presumably a persistent globally unique identifier, the DNS-like identifier is no more than a temporary display name.
If the Data Repository goes offline, and as long as you have a backup of the post history, the post history could be uploaded to a new Data Repository, and with the signing key you could sign a "update_atp_pds" and "update_username" message to point to the new location, and send those signed updates to all your followers' servers to give them heads up of where you moved to, even with the original server going offline.

That's at least what I understand of the spec from reading it, or how I think a hypothetical implementation would make it useful.