Git was not first, and it arguably didn't achieve its dominance based on technical superiority. It almost certainly didn't achieve that dominance based on offering a better learning curve or a bizarre interface choice, even though I might personally understand and appreciate the relative tightness to its underlying systems. I also don't think we should defend a technology or tool by portraying it as a sort of null-hypothesis, a default automatically suitable for anyone except in special circumstances.
I'm currently making source control recommendations for my new client. No one there is a full-time programmer, and they mostly do engineering and PLC work, but more recently they have to work with higher level languages from time to time. They absolutely need something they won't have to fight to learn. Other times I've recommended source control during my career include tutoring first-year/some second-year university students, who are often still only becoming familiar with programming and CLIs, and for whom Git seems both arcane and stress-inducing, two things you absolutely don't want from a source-control system.
I am adamant that in neither of these above cases would git be the right choice. I'm also not convinced its the right choice for many development companies, which often have staff of a range of skill levels. I'm lucky in that I've nearly always been working with passionate programmers, where we can and do happily make the choice to adopt git without a second thought.