So the killer feature is not the possibility to report issues, propose and link corrections, enhancements and new features to be merged back, have them automatically tested on continuous integration bots, comment code online and have discussions about implementation correctness or style...
If killer feature is not the social part, then we don't really need github. Git, MC, or any other distributed VCS already handle the trivial ability to fork.
Forking is very important for handling concurrent timelines. But a good fork is a fork that is merged back, because it preserves retro contributions. If divergence of interest is too high, then yes, the ability to definitely fork is important, but it should be last resort decision.
IMO, time spent to convince that a change must be merged back is not lost time. Unless the change is not that good. A fork is a super easy and convenient way to handle the case in short term. But long term divergences soon become unsustainable drag. So please, be social and cooperative and favor win-win strategies :)