Reading some Mercurial documentation I found an interesting minor limitation.

Because it is usually impossible to merge two conflicting modifications to a binary file, centralized systems often provide a file locking mechanism that allow a user to say “I am the only person who can edit this file”.

A distributed revision control system cannot, by its nature, offer a file locking facility. There is thus no built-in mechanism to prevent two people from making conflicting changes to a binary file. If you have a team where several people may be editing binary files frequently, it may not be a good idea to use Mercurial - or any other distributed revision control system - to manage those files.

(Of course that "other distributed revision control system" is GIT.)

Sure enough this CVS documentation discusses file locking.

One solution, known as file locking or reserved checkouts, is to allow only one person to edit each file at a time. … Currently the usual way to get reserved checkouts with CVS is the "cvs admin -l" command…

I run a CVS server and we do have projects with binary files being centrally tracked. We don’t make so many contentious edits of binary files but I can imagine a game studio or something with a lot of integral binary assets (exactly like this) really finding this feature important. It’s definitely a consideration when deciding on the right concurrency/versioning tools and a reminder that there is no universally correct approach.