What properties of Smalltalk give it such a powerful IDE?

I think that there are a few factors that make this possible:

• Because "everything is an object," classes and methods are themselves objects.
• Because Smalltalk came from an era when there was (typically) not a separate operating system, it was expected that the IDE (code editor, debugger, and other tools) would be in the environment. Thus, creating a new class is not a language syntax but a message send; also creating a new method is not a language syntax but a message send.
• Because Smalltalk was originally interpreted rather than compiled, all the metadata (class schema, source code, etc.) is expected to be present.

These are related to but not the same as "the image based capabilities" that you reference. Of course, the unified image makes it easier to do retrospection.

I'm sure that others will chime in with other ideas.

The answers may depend on what Smalltalkers usually do within their Smalltalk IDE and specifically what they think they cannot do in another system. Likewise, non-Smalltalkers may counter with what they like about their IDEs and what they think Smalltalk IDEs might not offer (such as not crashing the IDE when your program crashes the VM).

I would like to highlight the debugging experience in Smalltalk. You can edit the program while it runs almost without restrictions. Nowadays, at least Java IDEs support the same with limitations, as far as I am aware. You can edit existing methods at runtime in Eclipse, but you cannot define new classes or change the "schema" of a class at debugging time (at least last time I tried to, which is some years ago).

This builds a) on the program being debugged running in the same environment as the IDE, and b) on the feature of Smalltalk systems to simulate their own VM to a certain extent, interpreting the byte codes in the debugger and being able to manipulate the sender context chain (call stack). Smalltalk's introspection and reflection capabilities, and everything being an object to which you can send messages, facilitate this. Since in Java the IDE process is usually separate from the process being debugged, they need additional debugging interfaces to talk to each other. Whether you consider that on par probably depends on where you draw the line between just the language runtime and the tools built around it to support an IDE.

Another useful property is that Smalltalk exceptions are resumable. They do not unwind the stack once they are signalled. That only happens when the exception is eventually handled. In contrast, systems like Java unwind the stack during the search for a matching catch block. Not unwinding the stack allows you to fix, restart and continue the piece of code that broke, without restarting the whole program or functionality or test case that lead up to that piece of code. Common Lisp has basically the same capabilities with conditions and restarts, but I do not know how exactly it is usually implemented with regards to stack unwinding.

That IDE and program under development share the same environment also makes it somewhat easier to build domain-specific development tools. The context switch between working on your program and working on an IDE "plugin" does not feel that big.

Somebody might be able to build a similar self-sustaining GUI around Lisp systems like SBCL. SBCL already brings the debugger, incremental compiling and updating of functions etc. So the questions about supporting live-programming are already addressed there. Compared to Smalltalk, macros, closures around functions, and optimizations like function inlining may affect the overall experience depending on how they are handled. (For example, do you have to recompile functions containing the inlined function yourself, or what happens to the closure state when you want to update a function inside.)

Even without such a GUI, I enjoyed the same live-programming experience that I enjoy in Squeak when I developed and OpenGL game with SBCL and Emacs/slime twelve years ago. That included changing/extending the behavior while the program runs, and fast startup and resume due to the image-based nature. In retrospective, using Emacs/slime feels more cumbersome to me than using a Smalltalk IDE, but this may just be a matter of preference: like whether you prefer to use gdb or a graphical debugger, or whether you prefer keeping your hands on the keyboard rather than using the mouse. Given enough experience, I believe you can be equally productive with either environment.

One difference with other (most) IDE is that Smalltalk IDE are not file-centric. Files are a terrific abstraction that brings nothing but useless complexification, a double address indexing to begin with.

In Smalltalk, we browse classes and methods, implementors and senders, and user never need to know at which line of which file would that specific method source code be stored...

For analogy, it's like ignoring that the file begins on sector 31712 of floppy disk A:, we don't need that information in traditional IDE, do we?

For Smalltalk, it's the same, just one level upper. Users should not have to think of their code in term of files, just as they don't have to think of it in term of devices and inodes. They should concentrate on the language structures, be it classes, functions, namespaces, whatever. And the IDE should focus on that structures.