Thanks for replying, I understand your position better now.
> I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself [in the GP]
The GP is mistaken. Their understanding of objects & refs seems different to how I've seen them refered to in the majority of git literature.
For passing readers: refs (branches and tags) are just git's way of labelling a commit (which are stored as objects). GitLab/GitHub don't do anything special to implement refs: they're standard git refs. They're not different, they're 100% part of git.
GitHub/GitLab do add a lot of extra refs to track things like PR/MRs.
> Branches, pull requests, comments, etc... should all be Git objects of some sort.
Branches can't be objects because you'd need a way to find them with a label, and then why not use the labels directly instead?
PRs and comments can be stored in a repo (as refs and notes), but git doen't have a strongly-opinionated view on the exact workflow you should follow when developing, and thus isn't interested in recommending that people should always use forks & CRs.
Right, there's no PRs/MRs in Git itself, but branches are there, specifically in that there's nothing about the existence of or use of branches in GitHub/GitLab that needs to be brought back into Git, that stuff is already there.
I recognize and accept the argument that it might be nice for Git to track merge-requests and issues (hence my link to Fossil SCM)
That's not how I understand refs, they don't even live in the .git/objects hierarchy.