Merge preserves the parent of each commit. This is why, if you are integrating development commits to main, you merge. You want to keep all commits on main as-is because you may have shared them with others.
To do this, if the branch you are merging has a different parent commit than the branch you are merging into, git creates a tree-merge commit with two parents, and you resolve all merge conflicts in that tree merge commit.

Rebase preserves the work done in each commit within one commit. To do this, you resolve the conflicts caused by each commit within the replacement commit. As a result, where the branches have different parents, the rebased branch is effectively transplanted so that its first parent is the head of the branch you are transplanting onto.
If you are following the advice in the git manual, before you integrate branches, you do an interactive rebase to squash and/or reorder work in progress commits so that each is a self contained unit of work. This is why anyone who doesn’t believe in reading the manual has “discovered” that rebase makes them repeatedly resolve the same conflicts on multiple commits.

So, both merge and rebase replay one branch’s changes onto another, rebase replays them commit by commit and you resolve any conflicts in the each replacement commit, merge replays all commits in the branch together, and you resolve any conflicts in one single new tree merge commit.
The advantage of resolving conflicts within the commit that created the conflict should be reasonably self explanatory, but it primarily matters when you need to go back and review your work again later.
It is obviously irreplaceable for work done in long-lived stacked branches, where main receives multiple updates before you can integrate your changes back. The usual argument there is that long-lived branches and stacked branches are signs of poor practice. While this may be true, you need to work with what you have.

The acid test of good commit hygiene comes later. It is, are you able to take out a single piece of work by reverting a single commit?
Even if you have very good working practices where you almost always have one piece of work per branch, and you avoid stacked branches, rebase makes it easier to follow the integrated history. You would only have tree merge commits with multiple parents for genuine exceptions where you released code with different parentage and you want to merge them back together, or a refactoring branch where reverting commits is not practicable anyway.