With Jujutsu it's not at all complicated. Sure, you may not agree with the example (and I would say its a little contrived), but rebasing into history to keep a clean progression of commits in a feature branch that is unreleased is something that many people are keen on.
Jujutsu also has a bunch of other really useful features like `jj fix` which can run a code linter over a linear commit history (in parallel) and integrate the changes into the commits that should contain the change. This avoids a litany of 'fix formatting' style commits littered through your history.
To give some specific examples, "many people" includes popular open-source projects like Linux and Git itself, as well as large tech companies like Google and Meta, which employ "trunk-based development" (see e.g. https://trunkbaseddevelopment.com).
Sometimes the "add the missing tests" step depends on other work on your branch.
In practice, what you describe is often the case, and having a quick shortcut to do "stick $small_fix in main via a separate branch, but yoink that commit into my branch before that first branch lands on main so I can keep working" would be very useful.
Historically, though, I usually addressed this need by copy/pasting the code into separate commits in both branches, and being careful to keep the $small_fix-to-main code and its twin in my larger branch un-drifted and textually discrete to make the eventual merge conflict a rubber-stamp to resolve. Ugly, yes. Maybe I should feel guilty about it, who knows?
And it is a lot of work. Even in the best case. I know it is because I used to do exactly this. But more often than not the small fix ends up getting affected by your changes in the branch and then you're in rebase hell again.