1. Stacked PRs. I like to be kind to my reviewers by asking them to review small, logically-contained pull requests. This means I often stack up chains of PRs, where C depends on B depends on A, and A is being reviewed. If I receive feedback on A, jj enables me to incorporate that change within A, and flows those changes down into my dependent branches. I can then merge and close out A, whole continuing to work on B and C. Achieving this in raw git is labour intensive and error prone.
2. Easily fix up commits. I like to work with atomic commits, and sometimes I realize that I've made a typo in a comment, or a small error, or missed a test case. Jj makes it really trivial to timewalk back to the commit in question, fix it and resume where I left off.
3. Decompose a big PR into multiple PRs. This is the flip side of point 1: I can take my own big PR and rearrange and partition the commits into A, B and C so that they can easily be reviewed.
In general, jj seems to encourage and reward you for being disciplined with your commits by enabling you to be more flexible in how you stage, review and ship your code.
On the flip side, if you're the kind of person who is used to typing `git commit --all --message "xxx"` you might not get as much value from jj until that changes.