It also allows you to stay unblocked the entire time you're waiting on these dependent PRs.
For "how they do it on github": the way we do it at Graphite (spoiler I work there), is that we make the unit of change a PR instead of a commit. ie. every PR has one small commit, and these get stacked on top of each other. The tool itself abstracts some of the complexity out of rebasing and managing all of these stacked PRs (which in the article are referred to as stacked diffs).
Does that make sense?
If PR2 is done before PR1 is merged I tend to put it up as a draft with the target branch set to that of PR1, and say it depends on PR1. Then the diff shown is only PR1..PR2 anyway.
AIUI what I don't get doing that is the ability to potentially merge PR2 before PR1? But then it depended on it for some reason anyway, so..? (And I gain the ability to still have multiple commits in a PR / reviewed 'thing'.)
The tooling in Phab (and Graphite) makes stacks much easier to work with by auto-rebasing the whole stack as you push new changes to base commits.
TFA seems to get hung up on reviewing individual commits instead of a set of them ('a diff is basically a commit' - err well yes) when actually the benefit per my guesswork and your description is more about the automation, and there's no inherent reason (as far as we've discussed anyway) that it couldn't be doing that with a set of multiple commits anyway.
Note that `git rebase --update-refs` lets you just rebase the last branch and the entire stack gets updated. You just need to know which branches to forcepush.
My guess is that it's more about somehow seeing a more 'contextual' (not semantic exactly) diff in the second PR? So rather than including all of PR 1's changes that it's based on, just showing the actual diffs in the commits in isolation, or as if rebased (only PR 2's intended patch set, not the master fork point through tip of PR 1) on master?
Though I haven't read further than I can as a non-subscriber, perhaps it would be clearer when it explains how they're doing it on GitHub (the above would require some rebasing or target branch and further PR automation).