Author here: The biggest benefit for me is the ability to work on change N+1 (or sometimes even N+2 also) while change N is being reviewed without subjecting myself to constant merge resolution if I need to update change N due to e.g. reviewer feedback, issues in pipelines, etc. `rerere` helps somewhat, but the flow is much nicer when I can just rewrite one commit and everything downstream updates itself.
The others are also listed in "the good" section of the article, but that's the biggest one. How much of a benefit that is for you will really depend on your usage patterns - maybe it's solving a problem you don't have. But the nice thing is since it's git compatible, people for whom this solves a problem can use jj, without having to migrate their whole team/company from git, unlike other solutions like fossil, darcs or pijul.
I commented on exactly this elsewhere in the thread. It’s hard to understate how insanely useful it is to be able to painlessly edit earlier history even when there are later threads of work based on it.
Also in my experience everyone says “my default workflow is easy” when you talk about an alternative VCS but in every other context they complain about how often that workflow starts getting exceptional: rebase conflicts, stash conflicts, WIP commits, uncommitted work accidentally blown away, etc.
I will say this is not a nix specific problem and also not trivially solvable by policy because of packages that contain multiple binaries as produced by the upstream developer (e.g. grep/fgrep/egrep, pacman/makepkg/pacman-key, , go/gofmt, ffmpeg/ffprobe, qemu has about a billion, etc.).
