Especially with statically typed languages, good IDEs make developers significantly more productive.
Programmers spend most time reading code, navigating code, understanding code. Much more than writing code. Unless you've only done greenfield solo projects in your life, you know this is true. IDEs have code navigation features and tooltips over types and methods. Features like this help a developer understand code significantly faster.
Additionally, code occasionally needs refactoring. Most common are the real simple refactorings: A method might grow too hairy and need a split up, maybe a method's name does not correctly convey its meaning anymore, arguments would have to be reordered for consistency, and so on. In a text editor, you have to manually update all references to the changed method. All you can do is compile (or unit test, in case of dynamically typed languages) until all the errors are gone. This is cumbersome, error-prone and time consuming. Search&replace often creates more errors than it fixes. IDEs have direct support for simple operations like these.
Larger refactorings are mostly compositions of smaller, simpler ones like I described above. Being able to trust the tool to have made the change correctly is invaluable in this process; it avoids a full unit test suite run after each step, and significantly speeds up major refactoring work.
The end result is that a team that uses IDEs and understands its navigation and refactoring features find it very easy to increase code quality. A room full of vi users, not so much. A text editor user would prefer to keep things as they are and add new features instead. The cost of minor refactorings, such as method renames, does not weigh up to the gain. This gain is small in the short run, because the developer is actively working with that part of the code. In the long run, repeatedly skipping these improvements makes code ununderstandable.
Also, let's not forget the "not invented here" syndrom. IDEs make it easy to figure out how to use 3rd party libraries and colleague's code with ease. Type the name of the class/object, press "dot" and you get a nice overview of the class's capabilities, including tooltip documentation. A text editor user has to task switch to the browser for docs all the time. If there are docs. Or read the source code that is being used.
This means that for relatively simple operations (say, a Point class, a string operation, etcetera), a text editor user will often find it easier to just write the damn thing right now. Its easier and more fun that scouring the code base for something that looks like it. The result is low code reuse.
In conclusion, correct usage of a decent IDE increases code quality, makes maintenance a blaze and keeps developers happy. Except the first week, when they're not yet used to the slightly odd UI. But if that holds you back, you're not a professional, you're a whiner.
I admit that IDEs have most value for statically typed languages (which, for me, is the strongest case for statically typed languages out there). Dynamically typed languages basically have the problem that they can't get decent IDE support, ever.
<sad rant>Which is why the web crowd keeps using TextMate and vi, keeps using Ruby and Python, and keeps writing increasingly unmaintainable code.</sad rant>