It can become a problem for when someone wants to make the switch from the consuming side to the producing side of things, or even just be part of a team that wants to do that. Every person first needs to be able to identify ones own faulty concept as misconception, and any decision made during this process involves a lot of risk.
For example, with the car analogy, you could have a very simple model that says that the accelerator pedal makes the car go faster - the harder you press the pedal, the faster the car goes. This model will break down, however, when you start driving in rough, wet, or snowy conditions. For those conditions, you need a more complex model that can take into account things like torque and grip. (I think: this analogy is taking me to the limit of my car knowing!)
I worked on a project involving a device that could be configured. The backend developer's mental model was that the device was always in a configured state, and that you could then save the current configuration as a kind of preset, or replace the current configuration from an existing preset, or just change the configuration on the fly.
The users, however, had a mental model more like files: they would load a configuration, make changes to that configuration, and then select a different configuration, expecting the previous configuration to be updated. In the end, these two mental models proved to be too incongruous, and we needed to switch the backend to use a different system internally that better matched user expectations. (Another option would be to build a UI that made the backend model more clearly.)
In the case of git, the problem to me is that both mental models (diff-based and snapshot-based) are true and shown in different places. If you rely entirely on the diff-based model, you can use git very well, but you'll get weird errors when you start cherry-picking commits. If you rely entirely on the snapshot-based model, you'll be fine up until you want to rebase something, and then git will feel like dark magic. Both of these models can represent a lot of git operations, but if you take them too far, both will allow you to make a number of assumptions that aren't true.
(I think there's also a nice analogy to physics as well here: Newtonian physics is a really good model of the way the universe works, it allows you to do a lot of very precise things with maths. But if you try and build a GPS system using only Newtonian physics, you'll find that your model doesn't match up to reality any more.)
The problem seem to be that the interface wasn't clear about whether it would save implicitly or explicitly.
Which makes me think leaky abstractions aren't so bad as long as they don't facilitate a mental model that works opposite to "what it leaks". Essentially it seems fine as long as it's close enough, like in the example of the car.
Sure, if they need to actually know how something works (because, say, they want to dig in and modify the system itself), then of course they need to understand what happens below the abstraction.
But if my goal is "drive a car", then it may not be helpful to know anything about that pedal beyond "car starts moving when I press the accelerator pedal". Because the nice thing is that I don't need to know about fuel injection or whatever happens when I press the accelerator on an ICE car. And the really nice thing is that if I switch from an ICE car to an EV, the basic usage is the same, and it doesn't matter that something completely, entirely different happens when I press that same pedal on those two different cars.
(Ok, well, now we have one-pedal mode on some EVs, but... otherwise...)