Programming

I don't get the first part on pull requests, you can't just say:

I’d like to see what other tools people can offer. Perhaps a tool that promotes ensemble working to share the problem solving and context with a larger group.

and then also say:

I do not know what these tools are or what they look like, and I’m not saying Pull Requests are all bad either. But I don’t believe that we’ve found the one-and-only way to work together on a code base.

You have to make a valid proposal to say how the workflow could be "improved" (if it really can be), otherwise we're talking about nothingness, the draft that is written in the middle is very vague IMO, what I'm really missing is what are the specific problems in the PR process, you say:

Pull Requests are a blunt instrument that puts gate keeping front-and-center

It's true and I don't see how things can work otherwise, the point made in the linked article (emphasis mine):

If I am messing about with something I have low confidence in, I will be very explicit in how I ask for help. Preferably at a much earlier stage than in opening a PR. But if I have high confidence in my code change, I would love for you to take a look, but I don’t expect you to spend too much time figuring it all out.

Confidence is completely subjective, some small change that you are confident will touch that place and only that, might well affect other parts of the code that you don't know about, and who knows about it? The people that have worked on that code. I've worked a lot on a codebase where the main developer stepped down from his role to do managerial tasks and he doesn't perform any code review at all mainly because the company doesn't value the review process, so there's no time for it, but also, even if there was, he can't remember anything he's written.
So it's not rare that I touch some code, approve it myself and a user notices that something broke once it has hit production, I was confident in the change I made and I was wrong, I couldn't have known that because I didn't have the full knowledge of the codebase.
When I'm not confident, I usually ask and get a little feedback, it usually helps, but it's not exhaustive, so some issues might crop up anyways, even still, I might be working on something I created and be confident, but my mind was hazy at the time of making the changes, so I make mistakes anyway.
That's why I believe that a strict review process is always beneficial, even for supposed "stupid" changes, because you're not editing a document, you're editing code that will run, a mistake somewhere has effects elsewhere and wrong code has no place hitting production if it can reasonably be prevented, those "small hotfixes" that are urgently needed to fix that broken thing in production will often lead to some other issue somewhere because you were pressured to think fast and get out a dirty solution which will likely cause some problem you hadn't foreseen in your supposed confidence further down the line.
What do we have on the other side, collaborative editing? A live feed of what the others are doing so anyone in the team can step in to help? That's spreading the attention of the experienced developers that I imagine would be involved in this collaboration too thin, they would have to waste time thinking what the mental process of the other developer is, even in an interrupted stage, where everything is up in the air, that is huge cognitive load, it makes way more sense to put that load on the single developer that has to refine their work until it's presentable, then, if they run into some problem midway, they will usually ask questions on logic and architecture, more so than code, and even if it is about code, their current codebase state can be pulled from their repository object of the PR to try out