In this case it was about being adaptable to the tools programmers already used. Smalltalk required one to buy into the whole thing - it’s an IDE with its own OS and GUI.
What if those already-used tools weren't as-good for writing Smalltalk programs?
----
> … its own OS and GUI.
Well there are examples of bare metal Smalltalk (I'm guessing we could say the same of Java?)
https://github.com/michaelengel/crosstalk
but that was kind-of unusual and afaik commercial Smalltalk implementations targeted specific host OSes.
----
Similarly back in the '80s commercial Smalltalk implementations provided their own GUI L&F (and in the '90s Java provided their CrossPlatformLookAndFeel aka Metal).
When OS GUIs became available in the '80s, Smalltalk implementations either targeted specific host OS GUIs (so on MS Win use MS Win controls) or provided portable GUIs based on emulated L&Fs (OS/2, Motif, MacOS, MSWin) (and in the '90s Java provided AWT/Swing…).
IBM Smalltalk (Visual Age) GUIs were based on what would become in the '90s Java SWT.
----
So no, not really "its own OS and GUI" — when GUIs became provided by the host OS, Smalltalk implementations provided ways to use the platform L&F.
https://news.ycombinator.com/item?id=29223880
> … storing source code inside a memory image didn’t help with interoperability…
"Interoperability" covers a lot of things, was there something particular you had in mind?