You've never maintained a long-lived git feature branch, it seems :)
I maintain a project that is a slight modification of a very active upstream repo. The changes I maintain are rather invasive. Almost every upstream commit introduces a merge conflict with my changes.
To keep myself sane I only merge/rebase when upstream releases a new version, but it still ends up sucking up a few weeks of my time every year. During those weeks, I look enviously at pijul where the conflicts would resolve down to a handful of corrections in context at the point of divergence, instead of gigantic merge conflicts obscured by thousands of piled on patches.
You say that, but this applies to all cherry picking you can do between branches as well. As long as they don't conflict you're golden, and if there's a conflict you can commit a resolution that'll commute with your branch until you merge back into main.
It would enable so many nice and less strict workflows to actually work if it ever got momentum, I've still got hope.
For me "not needing to pull before pushing" is nice, but not game changing (but helpful to understand nonetheless).
It's more the cases that you allude to that we instinctively avoid in git!