Git is extremely easy to "self host". What makes things complicated are the web interfaces around code hosting, and all their supposedly important features. These days, Prs, issues, forums, wikis and all that seem to be synonymous with "git", which is pretty weird.
Because there isn't really a good name. In FOSS circles the name "code forge" is often used, and then OP might say "git-based code forge" instead. But both Github and Gitlab don't consider themself (and aren't) code forges. The term doesn't carry the load of the product positioning. So "hosting provider for git" is a pretty good description imho.
Which is ironic because PR is definitely alien to git. There is no such git concept as a PR, nor git pr command.
Coming from a pure git workflow in mailing lists where branches, and commits(and associated diff and git am metadata) are the unit of work, I struggled to adapt into the PR concept in the beginning.
I liked to work with gerrit, where the unit of the review is the commit. This also ensured a nice little history and curation of the change set. The commit in github is not even in the main tab of the PR. It is like it is a second thought. Even in the review, reviewing by commit is awkward and discouraged.
What do you mean by supposedly?
The PR model is pretty much universal for a reason. I get why it is considered out of scope for core git, but it is by no means a weird fixation people have.