Welp, I guess there's me, but it does indeed seem like adoption of the new commands hasn't been very forthcoming - I guess that's what happens when "the old way still works just fine" - but personally I'd expect that more and more people will change to the new commands over time.
Yes, almost the entire company runs on the subset of git presented by Visual Studio and Azure DevOps. I would guess this is more and more common, and even the more obvious shortcuts available for many things through git itself will become more and more arcane.
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
More precisely git-lfs is horrible the way it works with Github and its insanely low git-lfs storage and transfer limit.
What ends up happening inevitably is that you add some file to git-lfs that you did not mean to.
Only half sane/insane way to fix this is to just say screw it and start a fresh git repository, hopefully with files that you salvaged before the whole git-lfs mess.
I am quoting Github documentation "To remove Git LFS objects from a repository, delete and recreate the repository."
https://docs.github.com/en/repositories/working-with-files/m...
You say that is user error. Of course, users will make errors.
However your version control tools should get out of your way not make your life hell.
EDIT: I felt fine using Subversion combine with Redmine for issues in mid 2000s
Why did we need to go to git for everything when we still end up remoting to/from centralized hubs?
I wouldn't be surprised if some of the work and rigour being invested in OTs and CRDTs, and multi-user collaborative editing in general leads to some breakthrough improvements in the source control space too.
Git goes back to the local RCS model and adds atomic commits to that model. That's how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turned out to be not a big deal and they allowed very efficient operations without the performance issues of e.g. darcs.
Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs.
There could be new command line interfaces but it has become harder and harder to kick away the incumbents. I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout.