I always considered this to be a false dichotomy, as there's really a continuum between text editors and what we tend to call IDEs. Let's pick Java as an example.
At one end of the spectrum you have very simple editors without any extension and/or abuse capabilities, e.g. Windows' Notepad.exe. Not a lot you can do besides adding and removing text, and possibly searching for it. Everything in a per-character level, no introspection in the structure of the current class or the whole project.
The next step in the editor/IDE spectrum either pulls in external tools or moves us towards "programmer's editors". Probably the best known example of the "toolshed" version is Unix. You still use a rather simple editor (plain vi, pico, leafpad…), but combine it with a plethora of text-based tools to manipulate the source files. grep, sed, awk etc.
As for more advanced editors, probably the first two features that bring us closer to the "true IDE" end are syntax highlighting and compiler output parsing, allowing you to jump to lines causing errors. Add some simple way to manage multiple files (i.e. a directory tree) and you're rather close to some earlier IDEs (outside of the Lisp/SmallTalk school).
At this stage, some simple parsing of the source files is often added, allowing you to autocomplete and navigate to some extent. Quite often some version of the ctags utility is used for that.
I guess that leaves us the biggest step: Going from such regexp-based ad hoc parsing utilities and modules to properly understanding the code, like the compiler or interpreter itself uses. This allows better completion and enables complicated structure-based actions like refactoring or context-sensitive search and replace.
The "power" of the editing component is pretty orthogonal to all that and I'd argue that this is the main dividing line. People wouldn't mind having better "integration", but are wary to miss all the editing and/or extension capabilities. Forced asceticism is relatively rare (outside of 9fans), it's just that quite often it comes down to a choice you have to make between high level and low level abilities. With the IDE you might be able to navigate and change a lot on a class point of view, but once you leave the syntax tree and there's little support for "common" editing tasks where you'd just fly through with e.g. emacs/vim macros. It would look like the "IDE" part is the more complicated one and so it's easy enough to add those missing text editing features.
If only. For some kind of reason, most IDEs (esp. the Java ones) aren't that good at extending their capabilities. If you're ever cornered by a horde of former Java developers turned zombies, shouting "Eclipse plugin" is pretty sure to reach even their rotting cerebral cortex and send them shambling away (if that alone doesn't work, add some "maven! pom!" into your mix). Meanwhile, there are working vim plugins and emacs lisp modules for any non-physical task (and probably quite a few physical ones).
From the other side of things, the success of making those editors into IDEs is mixed. For Lisp and some other languages, Emacs is one, but the Java module isn't quite up to par. Vim has its "eclim" plugin, which in conjunction with Eclipse might actaully get somewhere. But for most languages and development environments, it probably still comes down to making a choice.
One thing that I've found (although, again, there's nothing inherent in the distinction enforcing that) is that "IDEs" are better integrated with the language (singular, sadly), whereas the extensible editors are more integrated/adapted to the user.
As a final personal note: I generally don't like it when I have to be "helped" by my environment too little or too much. Some support is good, but if I have to consult the program all the time, it probably means that I'm wasting time and might not understand the solution domain enough. Waiting for autocompletion is a good example, for common tasks, I'd like to know things, not look them up all the time. And if it's rare enough, I'll probably be better served by reading the documentation that just hoping that this method with those parameters is sufficient.
And as languages come and go, I prefer to invest a bit more time in editors that will stand the test of time (which means a lot of hopping back and forth between emacs and vim).
For some languages, it's IDEs, though. That includes SmallTalk (because the IDE is that good) and Java (because the language is that bad).