That example, while technically correct, is a little bit misleading. From a practical point of view, the thing that Pijul/Anu both do is not "automatically resolve conflicts" but rather "allow repo operations to happen even in the presence of conflicts". In Git, if you've got a conflict, Git will require you to fix it before doing anything else. In Pijul or Anu, you can continue applying changes—possibly creating more conflicts!—in a way that's guaranteed to never throw away changes. At the end of that, a human still needs to resolve those merges manually.
But there are scenarios in which this avoids tedious human merges. Consider that I'm applying a series of patches which make changes in a file and later on walk those changes back, and run into a merge conflict there. In Git, I could squash those changes to avoid dealing with the conflict, but then I've lost history. I could apply the changes, skipping the relevant patches, but if those patches still contained useful work elsewhere, then I'd have to go in and resolve those problems manually.
In contrast, this same scenario in Pijul and Anu would just trivially work in a way that didn't produce conflicts. I would apply the sequence of patches, and one patch would produce a conflict… but because they can keep doing work in the presence of conflicts, then they could keep applying subsequent patches and apply the patches which walk back the changes, and in that resolve the conflict automatically, but unlike the Git approach where I flattened the changes first, I would still have the full commit history associated with that sequence.
Now, that doesn't mean that Pijul or Anu will automatically fix all merges. If you have two separate code edits to reconcile, you might still need a human in the loop to reconcile them. But the fact that they can keep making changes in the presence of conflicts allows them to avoid a certain kind of "busywork" that comes with managing git history.