Due to the distributed nature of git, that's not actually required. Any sourcehut project can merge branches that exist in different places on the Internet.
The feedback and reviewing process might be more cumbersome, but accepting code contributions is not impeded in any way.
I guess the various hubs, labs and buckets make it slightly harder to run malicious code on your own box, but the difference might be smaller than one would think.
Git was not designed for remote fetching from every menial contributor. Nothing was—it didn't make sense to.* The idea with git-pull is that it's for use among a set of frequent collaborators—so for a given repo you have a handful of remotes, if any. It was not intended that everyone would need "infrastructure to let others pull directly from their repositories". That didn't arise until GitHub decided to eschew with the traditional currency of open source (i.e. patches) and use branch merges for everything. By doing so they created the demand that is responsible for the current popularity of centralized hosts—which they just so happen to be. It's one big dark pattern, not very different from the way Facebook nursed the growth of their userbase by erecting barriers around their walled garden.
* And still really doesn't. Encapsulating everything with a new branch that lives on a public fork + a proposed merge isn't terribly efficient, being the wrong tool for the job and all... People convince themselves, though, to overlook the time/effort costs of that arrangement because it's what they're used to.
Surely it would be a million times more intuitive for forges to offer a "submit a patch to this project" feature?
What are you talking about? (The general tone suggests that you're refuting something about my comment. What part are you trying to refute?)
Of course I can't speak for the devs of PostmarketOS, but on my own projects hosted on Sourcehut, that's how I ask for alternative contributions coming from people uncomfortable with sending patches using email.