You missed the point. The analogy was: Git has more choice and like having access to exotic Ketchups that can be nice. But jj can do anything that git can, so in the metaphor, git gives you a ton of choice but jj gives you all the same flavors.
Now if jj makes you assemble several pieces and makes it more difficult to get the flavors, while with git you could just grab the correct bottle, you could argue that the choice git offers is not meaningless. But that's a hard sell.
I think by now, there is pretty good evidence that the complexity of operating git is incidental. It's the result of badly designed primitives the user has to interact with (index, stash, commits, branches). As always, once you have internalized the primitives and their interactions, the complexity (mostly) disappears. But if you frequently train new students in using git, you stay painfully aware of it.
I think you've straight up reinforced my example. The end result is the same, but the way to get there is different.
Depending on what your destination is, a different tool might ultimately turn out to be better for the job. Even if they're both representing their state in a compatible manner on disk.
You're probably just not realizing that the way you interact with git isn't necessarily how everyone does - and that other people might have usecases that you've never thought about... Because you're not in their situation. So you're only seeing one way to reach the destination, which is why the one tool always looks like the correct choice.
To be clear, my current day job really wouldn't get any value out of any of these features either. We're doing simple trunk development on various repositories with roughly 5 authors providing commits.
Almost no merge conflicts, the most anyone does is git blame to figure out when the line was edited etc. under these circumstances, commits are essentially fire and forget and you're fine only interacting with the repository through your ide even.
Nobody, including you, have produced an example of a workforce that's substantially easier due to gits model.
Either gits design is unnecessarily complex, or there should be a pay off to the complexity somewhere. Some flavor you can't get, or can't get easily, with jj.
I wouldn't need these features either, but I believe teaching jj to beginners will be easier than teaching git. This is further evidence that the problem is git, not the problem space and the need for different workflows: If a different set of concepts serves both power users and beginners better, at what point do we stop pretending that it's all just tradeoffs?
I’m working solo on a project, with trunk based development. I still find jj nicer to use than git. I do do pull requests but just to ensure that CI passes on every commit.
Now if jj makes you assemble several pieces and makes it more difficult to get the flavors, while with git you could just grab the correct bottle, you could argue that the choice git offers is not meaningless. But that's a hard sell.
I think by now, there is pretty good evidence that the complexity of operating git is incidental. It's the result of badly designed primitives the user has to interact with (index, stash, commits, branches). As always, once you have internalized the primitives and their interactions, the complexity (mostly) disappears. But if you frequently train new students in using git, you stay painfully aware of it.