The goal for SocialHub was to help support the evolution of the ActivityPub ecosystem better. The goal for Discourse was to add AP federation support via the plugin. I am not sure the extent to which the implications of “becoming federated” have been looked at from a product development perspective at Discourse, in practice for SocialHub it resulted in pros and cons. Only when weighing these against each other can we really say whether the feature was “for free” or came at a cost, imo. Knowing the cons is input for improvement.
The externality I observe is more fragmentation in the dev community in part due to a shift in communications to the microbloggosphere. Discourse has the product tagline of “The online home for your community” and NodeBB describes itself as “Next generation community forum software”. How federation impacts this concept of “community” is a worthy product management activity.
As an ‘end user’ I do not mind if an app calls itself a Forum software or something else, but I do know that each tool introduction introduces a high cost in crossing tool barriers, additional workflow steps, and maintenance tasks, that is often underestimated or even overlooked. For SocialHub a Forum tool is a means to an end: Healthy community that evolves the Fediverse.
In the past and in the context of Groups support I have advocated a lot for exploring what I called at the time “Community has no boundary” in more detail in order to support it well on the fediverse. See e.g. Standardizing on a common Community domain as AP extension?
Note that at the time, what became known as FEP-8485: Unbound Actor by @diogo was also under discussion (FEP is now retracted). This started as specifically targeting Group actors, make them independent of the server instance. This way the “community” can be spun up from groups, orgs and persons on any fedi software and still feel and act as a community. Now you can control the ways in which it can be accessed.