Small nitpick, the domain name used for a ATProto identity is decoupled from the server that hosts that users data. A username is established on ATProto by creating a TXT record of the users DID (essentially a public key). This is not identical to ActivityPub, because the users data is hosted / managed by the server that the A/AAAA record points to. ATProto users can migrate their data from server to server while maintaining the same username. ActivityPub users cannot.
Also, Bluesky is a centralized view of the data in the decentralized ATProto network. This means you will never end up having the problem where searching for a user on one instance will not show up because they are on another instance that they have not federated with. There are obviously tradeoffs with this, but IMO they do seem sensible. The nice thing about Bluesky is not that it is decentralized (it's not), it's that the data that it let's users interface with is decentralized, and if something goes south with Bluesky, another application can be built on the same data and users can migrate without starting from square one.
This solves only half of the problem (migration). It doesn't solve the problem of different people signing up on different servers using the same handle. Is there anything stopping me from making a stephenking account on another server?
My "nitpick" was on the use of the word "server". The domain name used for a username is decoupled from the server. But no, there is nothing stopping you from making a stephenking subdomain on another domain. Just like there is nothing stopping you from making a website at google.mycoolwebsite.xyz.
But there are moderation lists that you as a user can subscribe to. It wouldn't be hard to find a moderation list for impersonators, which would solve this problem for you.
Also, Bluesky is a centralized view of the data in the decentralized ATProto network. This means you will never end up having the problem where searching for a user on one instance will not show up because they are on another instance that they have not federated with. There are obviously tradeoffs with this, but IMO they do seem sensible. The nice thing about Bluesky is not that it is decentralized (it's not), it's that the data that it let's users interface with is decentralized, and if something goes south with Bluesky, another application can be built on the same data and users can migrate without starting from square one.