This is a very reasonable and common question (I asked it myself before joining the team)

Account portability is the major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements. Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.

Other smaller differences include: a different viewpoint about how schemas should be handled, a preference for domain usernames over AP’s double-@ email usernames, and the goal of having large scale search and discovery (rather than the hashtag style of discovery that ActivityPub favors).

https://atproto.com/guides/faq

Also, I'll gladly eat some humble pie when BSky is actually opened for 3rd parties and federation.

I just know I've been burnt, as have many colleagues, on expanding companies stuff. And then them modifying/eliminating APIs.

It also is a PITA that "Open" is now a buzzword, rather than FLOSS. (For example, I'd call OpenAI anything but open.)

During the early days of what would become Bluesky, they first reviewed the available options for decentralized public communications and nothing out there checked all the boxes. So they moved forward building something completely new that did.

I wrote a comment last week diving more into this: https://news.ycombinator.com/item?id=38660192

It has no overlap with ActivityPub, it's an entirely separate protocol

ActivityPub wasn't the first federated web discussions protocol. It isn't even a good one. Given how few users use ActivityPub-based services, it makes sense to experiment while the window is open.