Slightly off topic, but related: I wish we could focus less on which git host is "best" and more on figuring out workable interoperability between them. Sadly, it seems less of a technical challenge and more a question of motive.
All it takes to host git proper is a network-accessible machine with git and ssh. It's the trivial part.
Making it convenient for you to communicate with other varied humans contributing to, or otherwise interested in the code, is the key differentiator. And apparently this is not the part SourceHut prioritizes. No wonder, because it's the hardest part.
Just because you don't seem to understand or agree with another person's priorities doesn't mean that they don't have them. By my reading, contributors to SourceHut absolutely do prioritize tools that humans use to communicate, and in particular ones that have been demonstrated to support complex and nuanced technical discussions.
SourceHut is new, and likely has a ton of competing priorities.
Also, different groups have different preferred styles of communication. (E.g. chat vs email vs forums is a typical divide.) Different places offer different styles, and this is great, because one size often does not fit all.
That said, most people are conditioned by using GitHub, and this sets their default expectations. Then the network effect kicks in.
We can easily define a niche within which GitHub-awareness can be presumed but it's certainly not "most people".
You want it to be something that it isn't.
All I am looking for is a few interoperability features for the repositories themselves. In fact, if I were to describe the most important single feature, it would be something like this:
I am able do some work in my repo hosted on host A, which was originally cloned from a repo on host B, and offer it back to the author on host B to merge if they wish. I'd like to be able to do this by notifying them (in a way integrated into my workflow) with the same kind of information that `git request-pull` generates. Importantly I would not need an account on host B for this. Possibly this might need some one-off setup on the original authors side, perhaps adding my repo as an remote.
The use cases I have in mind here are mostly occasional contributions or minor changes. I don't think this would work well for people who are frequent major contributors - they would really need the discussion / issues aspects to collaborate effectively.