Smalltalk single-handedly invented "the tooling", thanks to the various "browsers" and refactoring and testing tools, all made possible because of the dynamic nature of the language, which made the code almost its own runtime representation.
> the performance
Smalltalk pioneered many JIT techniques in the early '80s.
> the VM, the GC
All Smalltalks, as far as I can tell, are garbage-collected and run in VMs.
> the libraries
As a sibling comment states, that's what you get after decades of usage; can you tell with any certainty that Smalltalk would have less libraries, were it popular for longer?
(Actually, there are objective problems with distributing libraries in Smalltalk, stemming from its "everything in global namespace" nature; there were many systems designed to alleviate this problem.)
> is dynamically typed so there are very few refactorings that can be performed safely without the supervision of a human
I'm afraid you don't understand Smalltalk environment in full.
In an ordinary language, the code you write is just text. The type system adds certain information to the bits of text on your screen and prevents you - via compiler errors - from arranging the pieces of text in a way which would probably make the program explode when run.
It works most of the time, except when it doesn't and you end up passing void pointers and Object references. In effect, instead of only dealing with the type system, you have to deal with both static types and runtime behavior. I guess you just like it.
When working with Smalltalk, however, you work in a live environment. In Smalltalk, there is no source. Whatever you write is not just text - it's alive, then and there, and the system can trace each identifier and get its runtime type as you type, including concrete types of polymorphic types and other constructs frequently impossible to check with a static type checker in most languages.
In effect, Smalltalk gives you more contextual information to work with than most statically typed languages. Were you ever puzzled about which overload of a method (of polymorphic classes) will be called in a particular scenario? In Smalltalk, you can just ask the system and it will tell you.
Coupled with other features of the language this makes it really easy to perform automated refactorings. As others noted, the very notion of automated refactorings come from Smalltalk. I'm not very familiar with Java tooling, but I'd be really surprised if it enabled anything more than what Smalltalks offer.
In summary: static type systems are not the only way of adding contextual data to the source. There are other, arguably more powerful (access to the "real" runtime types) ways of doing it, and Smalltalk implements one of it.
Don't worry, though - the misconceptions you hold are very popular and it's not your fault for believing them. The problem with programming is that it evolves pretty rapidly, with many approaches failing along the way, that it's rather impossible to provide a comprehensive summary of the best ideas; and without such a summary we rely mostly on gossip. Moreover, the benefits of some approaches are very hard to grasp without experiencing them first-hand, and who has the time for that?