Earlier quoted context omitted.
Splitting changes into multiple commits is a much worse experience if you actually have self-contained dependent changes. 1. The whole review interface isn't set up for reviewing individual commits. 2. You can't merge changes progressively. 3. CI doesn't run on each commit. 4. If you have linear history (good idea IMO) you'll lose your nice commit history when you merge it. This is much better.
You can read each individual commit and review the PR as a whole. This is the way many people design and review PRs. You don’t need to merge those changes progressively. If you do, you go through exactly the same process of creating a separate branch and PR. The only difference is that GH has now added some UI and automation for rebasing and merging the PRs. In the past we would have explained the chaining in the PR…
When you have written and submitted a flob for review, you often want to continue your work on top of that, and then you may end up with a second dependent flob that is finished before the first flob is merged.
You want both to be reviewed. You want CI to run on both. It's simply a much better experience if flobs are PRs rather than commits. I dunno how else to put it.
> stacked PRs were a thing before GH made these UX improvements
Not in a way that worked properly. You could sort of do it for PRs within a fork, but it was impossible across forks which is the way most open source GitHub PRs are done.