In atproto, you can swap hosting (without changing apps), and you can create and use different apps (without changing hosting). That's the thing you can't do in Mastodon because it hard-couples hosting + apps into monolithic "instances".
In Mastodon, "receiver" and "sender" talk to each other, as you say. In atproto, hosting servers never talk to one another. The data from them flows into apps.
You're right that there's often a firehose in the middle, but that's also misleading. There doesn't have to be one firehose — there's a bunch of community-ran ones. It's relatively cheap to run one yourself these days (about $30/mo). It's easy to pool them between apps. And many apps don't use Firehose at all, and instead query community indexes like Constellation (https://constellation.microcosm.blue/). So "one firehose" is misleading.
>I say “Mastodon” here because if I say “ActivityPub” instead, a crowd of people will show up and say that actually what I’m describing is how Mastodon chose to implement ActivityPub. Whereas ActivityPub by itself does not really specify how to actually use it in practice.
I understand there's other ways to use AP, but when people say "where are Bluesky instances" they are specifically comparing AT to Mastodon's AP topology.
Running an AppView for your own app is not expensive at all. It can be as cheap as you want. It's only expensive if you want to store gigabytes of Bluesky posts and serve them to millions of users — i.e. if you want to build the full Bluesky AppView. But why would you want to build a Bluesky AppView? That's part of what I'm alluding to in my article — atproto isn't "for Bluesky". You can build any social app.
The problem is that that sounds like "you shouldn't want to compete with Bluesky". Which makes it dangerously centralized.
I like the concept of working like RSS. I don't like the idea of having a massive ecosystem coordination problem with game-theoretic network effects, for any component of the system.