Because it's the default in most other tools, and people coming to Team Foundation Server found it frustrating that they would have to explicitly tell the tool to automerge. More to the point, people didn't even find it obvious that they would have to explicitly tell the tool to automerge and complained about the sheer number of conflicts produced by merging branches, because in many tools, users aren't even told about a "merge conflict" until it can't be automerged. Thus it appears that Team Foundation Server failed to do a three-way merge properly.
Obviously, the correct default here is a judgement call. I didn't make it, but I support it.
I worry, though, that this change in defaults is exposing some issues in your merge workflow. Automerge can absolutely produce results that a human wouldn't produce, there's no question about that. But it's a well-established standard and generally considered safe, useful and generally correct.
If this is somehow "dangerous" then your process should catch that long before you check in. Hopefully you would have built locally and run a full test pass long before you check in and your continuous integration build would also catch these errors if you failed to do so.
If automerge produces incorrect output, you can always merge the file by hand. And, of course, you can also just turn the automerge option to "off".
