This is more of a cultural issue than a technical one: they want to attract mainstream programmers to their system, and the mainstream pretty much expects git compatibility.
I was the same way when I first picked up Squeak/Pharo. Only when I really went deep into it did I start to appreciate Monticello for its simplicity.
I hope that the Pharo/Squeak people keep both options around for a long time.
Git makes sense for Smalltalk in one sense: If your purpose is to create the perfect Smalltalk "image" or a set of them one after another then it makes sense that we have a single set of source and a single repository for it. This is so if you view the whole image as a single application. Like say you would view Linux as the single application whose development your VCS was created to support.
But if you view the image as a "workspace" where you are developing multiple projects and multiple components which ideally could be shared among multiple developers working on different applications, then the trad. Smalltalk change-management makes more sense. You want to track the versions of individual components/classes/modules, not just the version of the whole image. (Maybe you could call this the Cathedral vs. Bazaar?)
Saving the whole image --which Smalltalk developers do many times a day-- is similar to creating a version of your whole repository.
Individual developers do "branch" by having their own copy of the initial image. At some point they need to merge (or rather "combine" see below) some components from their images with components produced by other developers.
The difference is that in Smalltalk the merge happens by combining specific components/classes/modules, not by trying to automatically merge the whole "image".
Because of the component-based model of Smalltalk it is easy to divide the work so that each developer works just on their own classes or even on just their own methods of a class. Then "merging" is mostly a non-issue, you just combine the latest versions of different classes and methods from different developers.
Why is traditional "merging" needed in the first place? Because to accomplish something you may need to modify some existing source-file in some way. In Smalltalk instead you could subclass an existing class and make your fix there, and use the new subclass instead of modifying existing source. (Ideally).
