The blog post seems to specifically answer this question far better than anyone here could. It essentially formalizes a workflow like the one you describe.
Remember than anything GH does “can be done by email”, to cite some early commentary. But collectively, the ease of use, and defaulting to best practice, that GH introduced have vastly improved and enlarged the open source community.
I know I never submitted patches in the 10+ years in the industry pre-Github. Now, barely a week goes by without at least one PR.
If you are happy with your workflow you can continue as usual. In other work-cultures people might not like your approach which is why a draft PR can be helpful. Basically what this feature does is that it avoids having to point to a branch and tell your coworker that it is WIP that you want feedback on. Usually a PR will also show the changes directly.
I've used sr.ht for some time and it's not that hard to work with e-mail flow. It's still not as easy (the main problem is setting up SMTP settings but that's done once). From my perspective most of the issues with git that GH solves is tooling, that same could be achieved with ML.
That said, having worked with git internals and models of repo access I'm pretty sure GH introduced forks to work-around the issues with repository control. Conceptually there is no need for forks, one could push to private branches of the target repo directly. Unfortunately git doesn't have tools for per-branch level controls directly. More details in https://github.com/rescrv/gitswitch
Remember than anything GH does “can be done by email”, to cite some early commentary. But collectively, the ease of use, and defaulting to best practice, that GH introduced have vastly improved and enlarged the open source community.
I know I never submitted patches in the 10+ years in the industry pre-Github. Now, barely a week goes by without at least one PR.