The idea that Smalltalk is a fully featured system which provides you with everything you might want to do with a computer reminds me of Emacs and Temple OS. Also, the blog I mentioned above seems to present Smalltalk as the perfect programming language.
Learning Smalltalk gives you three things:
1. An understanding of Smalltalk, the language. This is least essential. It's also the kind of thing you can pick up in a single 30-minute session. The language is tiny and simple.
2. An understanding of the design idea, uniformly object-oriented programming. This is crucial and will connect with other styles of programming including Actor-based and pure-functional. This is something you will never get from Java, which is not a uniformly object-oriented language.
3. An understanding of a completely different and (these days) unusual way of designing an operating system. An object-oriented operating system, to boot. The IDE, the debugger, and the other tooling all integrates to give a level of manageability in many ways far superior to e.g. Unix or Windows.
After a while, you may find yourself discovering subtle things about the interplay between the three aspects of Smalltalk that you can then apply in your own designs. For example, Smalltalk is a "dynamic" language, but the way classes and methods are arranged is very rigid, giving a lot of static structure to the system organisation. This static structure is what unlocks the powerful tooling, and is what simplifies the programmer's mental model to make the system understandable. Comparable OO and almost-OO languages, such as Python, have a more "dynamic" system organisation, making it harder to write tools for automatically manipulating Python systems and making it harder for programmers to understand how Python code, data, state, and processes come together to form a running program image.
There are several things in Smalltalk not available in Java or Kotlin, and more importantly, a lot more not available in an equally convenient and elegant way. Because the main thing behind a language is how features are laid out and play together, not whether a feature is merely available or can be achieved with some workaround.
(And of course, Smalltalk was created 20+ years before Java, so there's that).
In Smalltalk for example everything is an object. In Java you have int and co, and the resulting non-uniform behavior that requires boxing.
In Smalltalk you write code in a live image, and this means you can save state and resume your programming and program from where you left, give it to someone else to run from where you suspended it, and so on.
In Smalltalk the programming environment and the compiler are one, so the language is part of the IDE. You have total visibility of all objects, can edit them, query them based on their types, and so on -- and not just through some "ctags" type indexing.
In Smalltalk you can edit any part of the program, or IDE, and continue working with your changes.
What in Java would be a built-in operator like "if", in Smalltalk is accessible to the program to create, add variations, etc.
If you want to broaden your understanding of programming [0] then learning Smalltalk is worthwhile. A lot of ideas from Smalltalk have bled into the mainstream but it's interesting to see how a live image, integrated system functions.
If you think Smalltalk will be the next mainstream language, and you want to be ahead of the curve, then I wouldn't bother. That's highly unlikely. It's most suited for limited, self-contained and presentation heavy use cases. These still exist but they're not where the industry is or is likely to go. And it's hard to see pure OO coming back into fashion any time soon.
And as to perfection, well, as with all these things, it depends on what your building. It takes an inordinate amount of discipline to write a system that works well at scale. Even worse if you want to run distributed. It's really not suited for that. But if you keep in its sweet spot, it can be very pleasant to develop in.
[0] I'm assuming from your question you've had mostly mainstream language experience. If you're an expert Common Lisp programmer then this probably doesn't apply so much.
