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.
Then you have to use email for the review conversation, make the discussion easily available to everyone involved and future devs, track manually which comment refers to which line of the diff due to lack of overlaying, manually ping to warn of updates, rely on manual quoting, no direct information on whether the CI pipeline succeeded...
To me that feels like writing code using only sed. It is possible, but it removes or makes convoluted an absurd degree of regular work.
You can pull, but having the back and forth documented along with the code is not a nice to have imho
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.