There's not really any case where another source control system works better, but lots of cases where they work just as well.
Mercurial, for example, is functionally identical to git, but some people prefer its interface.
For a highly centralized organization where people only ever work on the organization's intranet, a centralized source-control system like SVN works well enough, and may have some advantages for the organization.
Actually, I found one just by reading this thread :
Fossil has integrated Bug Tracking, Wiki, Forum, and Technotes.
Which is great since I would prefer not having to worry about backing up these in the first place !
(Then git also has git-bug for at least some of this functionality...)
Git does not handle really large repos. You can search the internet for the term monorepo and see what organizations like Facebook, Google, and Microsoft are doing about that. None of them are using plain vanilla git.
Git is particularly poor in scenarios such as two people working on the same branch. SVN handles this with ease, but with Git it takes a lot of coordination amongst both contributors to keep things working.
I do not believe that is a good pattern. First, two devs probably should not be touching the same functionalities (if they are, they ought to be basically pair programming). So diffs should be orthgonal. If diffs are landing in the same branch, each dev should be using their own feature branch, and ideally PRing them back to the branch, but for small hacks, merge is fine.
Think fractally. The farther you get from master, the smaller and more atomic each commit should be.
If your merges are taking lots of coordination or failing to auto-merge, you probably have some poor engineering hygeine at play. Every time I've had merge fails, it's due to haste/sloppiness or a dev branch diverging too much from a mainline.
