FWIW, I am also one of those people who does not want to fine tune their tools. I want my tools to work well out of the box.

> I’ve only tried it solo hobby projects.

If I can surmise a bit, this is probably why it's never felt "worth it". I'm guessing that for a hobby project you don't really care that much about crafting small, easily-digestible PRs or keeping a clean history. `git commit -a` every now and then is good enough, and that's entirely reasonable.

For team projects, jj becomes a much bigger deal. I find it invaluable for splitting up a day's worth of work into small, parallel, easily-reviewable changes. While working on one feature I might run across a dozen other things that should be fixed, improved, or otherwise changed. Bundling them into one giant PR is bad practice and causes reviews to take much longer.

Carving those up into single-purpose PRs that can be reviewed in seconds and tested independently is super helpful on a project with multiple teammates. But that's not something that really matters or that most people care to take the time do to in personal projects. Hell, it's something a lot of people punt on a lot in git due to the extra burden of doing so.

I use Sapling at $DayJob. It’s pretty good and I largely like it. jj seems much less friendly for most operations. Although jj’s merge conflict stuff is appealing (in theory).

But you can't make a default that everyone will like. The best overall interface will have someone hating it. If you want to always use defaults, you're basically guaranteeing that you'll hate some genuinely great software one day.

I can’t spend a dozen hours fine tuning every single piece of software I come across because it might maybe possibly be great if I do.

If I used Git as part of a large team I’d perhaps spend more time with jj. But for solo projects it adds even more complexity to Git rather than reduce. So I don’t feel strongly inclined to spend that time.