It seems even more complicated to track 3 context points in time rather than 2.
I'm open to changing my mind, but would need reasons. Botched rebases aren't a common issue for me (though merge conflict resolution can be unpleasant).
Of course, if seeing my code and their code works for you, then by all means keep doing what works.
You know from the regular two-part conflict marker that developer A wants the code one way, and B wants it some other way. Often that is quite easy to understand and resolve.
But sometimes it's useful to know the original: what is it that A and B started with, to produce those divergent sections of code?
That may be helpful.
It might not. For one thing, suppose the rest of the code merged. That means that in the rest of the code you don't see anything original.
You could end up with:
<<<<<<<
new_function_x();
========
new_function_y();
||||||||
function_that_no_longer_exists();
>>>>>>>>
A and B both deleted the function, and that didn't conflict. Nice to know, but the definition of it isn't present to know what it does.
In other kinds of situations, it may be useful.
diff3 has another advantage in the general case as well since it allows you to better understand if something outside of the hunk you're applying also needs to be changed when backporting something.