That's great that it has things you like. I don't do rebasing, except on MRs where I've come to prefer squashing the branch being committed.
But I don't rewrite history. It's history. While I can understand people have reasons to do it, the reasons have never resonated with me. I'd rather spend my time getting new work done and not polishing work I've already done.
I'm excited for your delayed comment. I'm sure going to take note that you delayed it and come back later to read it because I'm super interested in what it is that you've delayed. You know, you can just write the comment instead of holding your place in line
Using jj is easier when your whole team uses jj. When the rest of your team uses Git, it's understandable that the pains of keeping up with Git-isms (e.g. constantly updating branches) start to become quite inconvenient. Though once you get used to jj they're not much of an inconvenience at all, they are still extra steps compared to raw Git. So if jj doesn't have any other inherent value to you it makes sense not to make the jump.
To me, jj has inherent value because I do a lot of things raw Git makes difficult or impossible. For example, https://github.com/LoganDark/fabric-template supports every point release of Minecraft since 1.14, and mods like https://github.com/LoganDark/debrand derive from it. I often rewrite the history of the template with configuration improvements and then rebase the histories of each mod on top of it.
This keeps my project setup consistent throughout versions, and consistent between mods, and allows all my mods, across all supported versions, to benefit trivially from all improvements I make to my global template. This workflow is either not possible with git or would require slow, ugly and fragile scripts.