Requiring megabytes for a base system image (although it could be stripped and compressed) the Smalltalk runtime was once considered too large to be shipped with individual apps, and apps tended to be slow and unresponsive compared to compiled C apps. There may also have been licensing issues with shipping a runtime environment.
Fast forward to 2022. Compared to current app sizes, it's laughably small. Compared to Electron/web apps, it's probably faster and more responsive. And the licensing issues have been solved with open source versions.
Those sound like nice systems and stepstones to where we may be today:
- fully free/open source implementations
- native widget integration (or we don't care anymore because we're used to crappy web apps)
- the resource usage and responsiveness gap between commonly deployed apps (such as JavaScript and web apps) and Smalltalk apps has either evaporated or is less of an issue because of faster hardware and more memory
But as you may be implying, I think that there are additional barriers to Smalltalk being used more commonly, such as unusual syntax, a different workflow compared to Java/Python/Javascript/etc., lack of type safety (note that even Python and Javascript have typed versions while typed Smalltalk doesn't seem to have caught on) and the fact that it's neither considered a web technology, nor is it promoted by influential platform companies. I suspect that the Pharo people might think that Smalltalk has a bad reputation (or something) so they never say "Smalltalk." I tend to think that not calling it Smalltalk leads to a bad outcome of confusion and fragmentation.
