With YAML and whatever format yarn.lock was in, the only changed lines are changes to the version resolutions, hash and dependencies.
I don't know how restricted their YAML subset is, but in my experience it's so loose a format the only way to be sure YAML says what you think it says is to run it through a parser.
Yarn will actually do the merging automatically — if you have conflict markers in your lockfile, just running yarn will parse them along with the rest of the file and produce a new lockfile with the changes from both diffs (unless there's a genuine conflict).
I assume that this feature won't go away with the new lockfile format
Hopefully they'll be able to re-use much of that work for the Yaml file.
Fortunately as someone else replied, both yarn and npm have safe and easy ways to resolve merge conflicts in their lock files.
What is the largest concern about YAML is that truncated documents are almost always still valid documents. The likelihood of that happening compared to, say, a git merge gone wrong is much lower, but the consequences are likely much worse.
I don't have a strong opinion on structured data file format, but that's an issue with YAML that often goes unmentioned.