I’d say that’s pretty much it—querying the database locally for subscriber counts was probably a very simple feature to add, at least versus collating totals from other instances (perhaps would need more data sending over activitypub to facilitate it)

That and it helps pick communities to subscribe to, so there’s value enough in the local count to be able to determine at a glance which communities are active, without having to go into each one.

Not sure how lemmy implements this, but I suppose it’s not a trivial task in such decentralized environment. Imagine 10 users from instance A subscribed to instance B and then instance A went permanently down. If B holds number of subscription requests it’s now out of date. If B has to poll every instance it’s federated with it’s additional arguably unnecessary load. So yeah local subscriptions are a low hanging fruit. I guess one way to solve it is to have some independent authority that keeps track of sub counts in case those are (made) public and queryable

I want to preface this by saying that I really don’t know anything about Lemmy, but I can see where subscriptions are managed by the subscribers servers in a federated situation: the community’s server might not even know who is subscribed to it since the subscribers server might be responsible for pulling data.

But any individual subscribers server would know about other users on that server that are subscribed to that community

Main reason for showing accurate user counts across instances is to give an idea of how active the communities are at a glance.

People will probably think twice about joining a community with low numbers, and it normally also causes those communities to be harder to find in the first place.