As a former professional Smalltalk developer, I would caution against the experience of greybeards who wax lyrical about the incredible power of Lisp and Smalltalk, because even in their heyday that power was largely illusory.
Firstly, anybody who encountered these environments early in their career will always be misty eyed about them.
Secondly, ask them how big the team was they were working in and what the mechanism was they were using to deploy their programs. Smalltalk in particular is particularly difficult to package up into a deployable program that somebody else can run, and collaborating on development is fraught with code sharing issues you just don't get with less exciting environments like .NET or Python or Javascript/Node.
In a modern context, Smalltalk and Lisp make little to no sense, especially when you have available a rich system of code being shared in more prosaic environments. It's a modern miracle that you can build what you need without re-inventing the wheel. There is no better time to be a programmer than now.
Lisp and Smalltalk may well be great for reinventing wheels, for writing un-readable self modifying code and as a challenging intellectual exercise, but all your productivity just went out the window.
Interesting. I did 20 years of professional Smalltalk development as well, 6 years at Cincom. This coming Wednesday will mark 10 years out of the balloon, wandering in the wilderness as a polyglot. My conclusions are not the same as yours.
Smalltalk was (for me) unparalleled at modelling things, including its own self (pun?). I think it also thrived in an era where a high percentage of the programming population pursued it as a form of mastery. The percentage of people that still program with some sort of mastery of the art is much lower now (to wit, I think there are more of them total, but less as a percentage). Working with the stack of internet technologies is like becoming a city planning engineer, a little bit of engineering, a whole lot byzantine rules and policies to navigate, jobs creation program itself in the number of "specialties" that need to be mastered to assemble anything.
I left Smalltalk, because the number of places I could advocate its use was shrinking. Desktop was dying. There's not a lot of technologies for browser delivered programming where going outside of the mainstream is worth the impedance mismatch it causes. And when it comes to handhelds, the hardware vendors have cobbled such an oligarchy of "use our approved/supported technologies" that it's rarely worth it bucking the idiomatic trends. All mainstream code movements live and die on the blessing of iOS, Android, or the browser(s). There's a small remainder of competitive evolution that goes on in the server space, but not a lot. Node may be more modern than Fortran, but half of the basic programs running on the backside are simple enough it doesn't really matter what you write them in, you could write them in Fortran or Basic.
I miss Smalltalk's simplicity. I miss Smalltalk's block closures: sure did make ad hoc functional program easy. I miss Smalltalk's very nicely balanced syntax: kind of code like, but also uncannily natural language at times. I miss Smalltalk's ability to try and see code and code artifacts as something other than text files. I miss Smalltalk's code navigation and execution tools.
Once Smalltalk became a commercial offering, with the need to support and maintain an installed base, it quit changing. Any vestiges of Smalltalk today, are basically Smalltalk-80+. For Smalltalk to "go on", they (we) needed to "burn the disk pack" again.
For me, the ultimate modern language would look something like Smalltalkish syntax and IDE, with Elixir/Erlang like execution semantics, but retaining a strong object/class declaration story (instead of let's pretend dictionaries are structures), and a namespace story somewhat akin to Python (but without the shadow binding behavior), and VM extensibility story similar to Smalltalk\X (unlike other Smalltalks which always ran into a when you got to the "performance" parts, Smalltalk\X just supported inline C extensions, so you could just optimize right in place, no JNI/FFI two worlds nonsense). And a world where delivery vendors (browsers, handhelds, etc) had an incentive to simplify program development instead of maintain status quos.
Smalltalk deployment was a PITA compared to compiling a command line tool from C, it was improving, but slowely. Ironically, compared to docker images and microservices and kubernetes and everything else that goes into any "complicated" program to deploy now days, Smalltalk was a breeze.
I have sometimes pondered whether to try making a system that kind of rhymed with Smalltalk, but using Roslyn[0] instead. Although I envisage it as being a kind of playground where you code like Smalltalk, with the artifacts being produced as conventional class files and whatnot so the final build could be done with the normal command line tools.