First of all, as you already pointed out, they require less work. In my opinion, the burden is on the process that requires more work—in this case the rebase process—to prove its superior utility.
The biggest argument is that merges preserve an accurate history, as the development actually happened. A linear, consolidated history is useful at a higher level of abstraction, such as the quality and release teams. It's quite the opposite on a development team, where it's extremely useful to know exactly when and how a bug was introduced. Did it happen because of a merge, or was the bug there during development and I just missed it? If the history gets destroyed, you have no way to answer questions like that.
The other reason is it encourages fluid cooperation in other than star topologies. In centralized version control, the only way to share your work is to commit it to the central server. With distributed, you might have two people working together for a day or two, pulling from each other, then they push to the central server once it's ready for the larger group. That's a very efficient and natural way to want to work.
If developers have to worry about if x rebased commit contains the same changes as y commit they pulled from someone else during active development, that creates a cognitive load that discourages that mode of cooperation. Doing merges offloads that tracking effort to the version control software, which is why we have it.