I think the intent is to not excessively duplicate content to conserve server resources, since when displaying any external federated content, it’s being loaded from the local copy on your home instance, not the originating instance (that’s simply how ActivityPub works, and I imagine it’s the only practical way to ensure that pages on your instance don’t hang if an external instance goes down or is just slow in general). There are three main problems with everything being updated live the instant the content was generated. It would result in a pretty sizeable amount of inter-instance traffic constantly as the network of instances all scramble to update each other, which would strain the server’s processing power and also use up network bandwidth, both of which could have been spent serving content to users instead of other servers. I imagine there is also concern with when an instance federates with another one for the first time, it would cause a massive burst of traffic affecting the performance of both sites if they synced their entire datasets all at once. Finally, having to store potentially a majority of the Lemmy network’s content on your server can easily get expensive as the network grows and more content is generated. All of these could potentially raise the barrier of entry to hosting a Lemmy instance pretty dramatically, in the form of server and bandwidth costs.

Though, I agree that the current implementation is not ideal and does get annoying. It also has the effect of preventing people from discovering new communities on other instances. Definitely still needs to be worked out as development continues. If you have an idea as to how this could be addressed or simply want to talk about it, I encourage you to make an issue on the GitHub page or in communities discussing Lemmy development!

That is expected, as your instance doesnt have any previous data of the community. If you follow it and wait for a while, the stats will increase as new actions are received over federation.