Think about the word "branch". If you have a linear sequence of commits that's one branch by definition. But you go and label the middle of that branch as branches too and then get annoyed when git, you know, does some branching there.
It's not an ideal way to operate for most shops, but there's really no reason you can't have a PR/MR/changelist/whatever that is a single branch with X commits on it and you ask the reviewer to review each commit individually instead of as a whole unit (as GitHub and other forges usually expect you to).
That and don't let reviews pile up such that you have 5 dependent in-flight reviews, something else is wrong if that's happening.
What is the advantage to this, other than maybe being easier to send over email?
To me, the important part is you have a logical "unit of change" that you're proposing to the codebase, whether that's a single commit or a branch or a jj bookmark or whatever seems more an artifact of the underlying transport layer (email or github or whatever) than any kind of intended functionality of the design.
- reverts are significantly easier
- bisect will work because the code is expected to code/run at every commit
- rebase becomes easier in the common case
- the transport does not matter, at all. Fully anonymous contributions are possible
- commit messages are easier to write because the changes are smaller and more focused
Several commits could encompass changes necessary to make a particular feature work (ie. patchset) but because each commit is self contained they can be reviewed and tested individually (in order, usually) instead of a one big diff. It's easier on the reviewer, though there's likely a bit more overhead.
Also probably most of us are stuck with whatever git*.com supports anyways...