There are many reasons why linear history is important. Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do.
A merge would only make sure that I don't need to resolve the same conflict multiple times. It wouldn't result in the conflicts not being generated in the first place, or them being saner. The only difference in conflict resolution between rebasing and merging is that the sides are flipped (what's shown on left in rebase, is on the right in merge, and vice-versa). Which doesn't address the second issue I listed: conflicts are not only repeated, but the conflicts themselves are pretty crazy. In my example, often-times C would never even touch files which were detected as having conflicting changes with A or B. It was pretty absurd that I would have a 3-line change in C, several hundred-line changes in A and B, yet the biggest conflicts would be triggered when rebasing C on top of B, and those would be in files C did not touch. Other times diffs in conflicts would have most of the lines added and removed actually identical, with only a couple in the middle different. Why would git mark them as conflicting, is beyond me. And then there was the issue of git not detecting conflicts, when it should have, instead merging changes in a way that broke source code. None of those issues is better handled by merging than by rebasing. Most of them however have pretty good solutions in a patch-based version control system, as opposed to snapshot-based like git (conflicts in files which weren't changed? not going to happen). An even better solution would be binary formats with domain-specific merge logic, like the one in KeePassXC.