The end result is that when you have two branches that have become even a little out of sync with each other when you try to merge them together SVN doesn't know what to do because all it can do is diff one version against the other. Imagine how this looks if you've spent a bunch of time refactoring in one branch, moving code around, deleting code, adding new code, etc. The end result is that you basically have to hand-edit each file into the final merge state you need it to be in, entirely defeating the very reason you use source control tooling in the first place. You might as well just print out all the code from each branch and get a committee to merge it all together using scissors and craft glue, it wouldn't take any longer or be any more onerous than it would be using SVN.
In contrast, more sophisticated VCSes, including hg, keep track of changesets, and they are capable of tracking those changesets as they move through different branches. When you merge in Mercurial it's able to trace through the revision history of a file in the source and target branches, find the common revision, then separately apply the diffs from the source and target branches, automatically check for conflicts (e.g. changes from both sides that touch the same blocks of code) and create a sanely merged final result which will only be flagged as a merge conflict requiring manual intervention when there's a high probability that there actually is a merge conflict. More so, the merge conflict will be presented in such a way that it's actually sensible, showing the actual conflicting changes and the resulting conflicting final versions of the file, making it fairly straightforward to resolve even in that case.
Casting this in the form of a real world example, consider a "main" branch with two dev. teams each working in their own child branches. For the most part each dev. team works on their own code within their own set of files, separate from the other team's, but there is some common code which both teams have a tendency to contribute to or change. Team A spends a bunch of time making changes in their own branch (branch A), committing as they go, then merges these changes up to main. Later team B merges their changes to main as well. Instead of running into a merge conflict nightmare that requires huge amounts of developer time be expended in sorting out the state of each and every file, the version control system sees that team B hasn't made any changes to most of the files in the repository, and most of the changes team B has made are to files that haven't been changed by anyone else, and there are only a tiny number of changes to files that had also been changed by team A's recent commits, which hadn't been merged to team B's branch before team A pushed their code up to main. However, most of those edits are to distinctly different parts of the shared files, and are automatically merged without human intervention, only a tiny handful of merges require manual intervention, a process that takes only a tiny number of people a few minutes to sort out. Some of those automated merges may, in theory, not be safe, but that is what testing is for, and the devs can still review and sanity check the merged files before committing if they like.
The ability to turn a show-stopping ordeal into a routine task can be utterly transformative to the development process. There are many big dev. shops that are reliant on dozens or perhaps hundreds of big merges (in multi-thousand file code bases) shuffling around code between various branches every day.