I dislike them reinforcing the component approach to delivering work through their examples, like the top screenshot showing "database schema changes", "api changes" and "frontend implementation" as separate branches in a stack.
So really, one does consider full stack a single feature, but unless they are reviewed in one go — which defeats the purpose of stacked branches and pull requests — you can end up landing one and a later review in branches higher in the stack needing changes in the lower branches even if they were already reviewed.
When you instead focus on full use-case per branch, but scope them down, it is much less likely you will need to change branches lower in the stack after they are reviewed.
Another obvious use-case is to do a pre-emptive refactor, though I actually prefer doing a post-refactor after the new use-case has been merged in — it's much easier to know the target best approach when you've got your use-cases right in front of you (or you may hit a similar problem as above).
FWIW, I remember fondly using bzr-pipeline plugin to bzr VCS ~15 years ago to do exactly this.
So really, one does consider full stack a single feature, but unless they are reviewed in one go — which defeats the purpose of stacked branches and pull requests — you can end up landing one and a later review in branches higher in the stack needing changes in the lower branches even if they were already reviewed.
When you instead focus on full use-case per branch, but scope them down, it is much less likely you will need to change branches lower in the stack after they are reviewed.
Another obvious use-case is to do a pre-emptive refactor, though I actually prefer doing a post-refactor after the new use-case has been merged in — it's much easier to know the target best approach when you've got your use-cases right in front of you (or you may hit a similar problem as above).
FWIW, I remember fondly using bzr-pipeline plugin to bzr VCS ~15 years ago to do exactly this.