I do know about NextSTEP, ProjectBuilder and Interface Builder. They were really impressive tools, but they were not alone as there were a set of VisualAge tools from IBM for various languages (including Smalltalk, C++ and eventually Java).
One important note in regard to IDE: for me it's a must for IDE to integrate very well with command line build tools. So, management of compiler settings as well as project management stuff should be done via configuration files for those command line tools. If they are part of IDE and code could not be built without IDE it's a showstopper for me.
Integration of debugger is an obvious requirement and it was satisfied even by Turbo C 1.0, not talking about more recent IDE's.
Benchmarking is a library functionality and I see no reason to have it built in into IDE.
Testing is also a library thing, although ability to run or debug one or many tests is definitely a part of IDE.
GUI tools are irrelevant for me and a majority of backend developers, so I don't consider them as necessary part of IDE and really don't care who should hold a candle to whom.
As mentioned above, compiler settings management should be part of command line build tools configuration. One thing I hated in Eclipse CDT was the need to configure a huge number of compiler settings in GUI.
As for Smalltalk:
I'm not speculating and know quite well how Smalltalk works and how it evolved. That's why I don't understand why you write that it was designed for IDE use, if there were no IDE's and there were even no GUI at the moment when the language was conceived and implemented.
There is nothing which prevents to implement the same model of code manipulation with another language. Of course, not all languages would be equally convenient in this role, but Java definitely fits here. It has complete support for run-time reflection (just like Smalltalk) and bytecode manipulation, including creation of classes, adding and changing methods is a bread and butter for several widely used java libraries. Technically there are nothing that prevents using Java in this role. After all Java inherited much more from Smalltalk than usually mentioned. And bytecode-based VM is also in this list. Finally, one of the reasons Eclipse introduced their own compiler for Java was a need to parse parts of the code on the fly, so internally Eclipse does exactly the same as Smalltalk IDE.
Yes, navigation, completion and other stuff works differently. But this is common for all tools across the board, most IDE's as well as editors have different keys for this. But this is configurable and I see no point to discuss that.
As for language servers: well, my experience was not so smooth because I did it some time ago. Recently I saw no point to spend time on this. Also, Atom and VS Code are quite heavy once all necessary parts are added. So, again there is no point to use them.
IDE was never positioned as something suitable for any language, so there is no point to blame them for the lack of universality. Situation changes though. Today it's possible to write Rust in purely dedicated to Java IntelliJ just by installing plugin. Of do the same with GoLand or CLion. The integration is pretty smooth. The only limitation is the lack of debugging in IDE's other than CLion (I guess because debugging backend is pretty much the same for C/C++ and Rust).
You can rip off Eclipse Java debugger, but it requires the platform to run. So, while I understand what you're talking about I don't think that only true modularity is the "set of independent binaries". Most editors and many other tools assume that modularity does not contradict to the presence of the common platform. And this common platform not necessarily should be Unix pipes or files.