Okay, this feels more like one of those questions where somebody needs to dig deep down and find the real question, which based on your comments, I suspect is:
"Is it okay that I hate IDEs?"
My answer would be "Bravo, yes. Over-reliance on IDEs to handle too much for you can make you weak and lose touch with the value of carefully designed architecture that ultimately makes a code base more maintainable with or without the crutch. Also, for devs who've really mastered less complex/lighter-weight tools like VIM they can do more to get in your way than actually help you."
But don't get too smug. Even if your code is clean and neat enough to be more easily dealt with in a non-IDE fashion, that doesn't mean everybody's is or that yours always will be if you find yourself having to continually add layers to something you had intended to refactor before you took it any further, but oops, now there's money and employees involved and you just need to get 'er done in time to see whether people get Christmas bonuses this year. (disclaimer: no, I've only worked for that guy)
It took exactly one legacy code-base from Hell to convince me that no, IDEs have their uses. These are:
Making the illegible less illegible - It is not possible to understand the code in a code base where every single class has a minimum of 1 interface and a super-class or a sub-class merely by looking at the code. It's just not. It at least helps to have something you can quickly find where stuff actually begins and ends.
Debugging crap-procedural wolves in OOP sheep's clothing - Sometimes you just have to give up and realize that all the OOP architecture is really just crap that further obfuscates what's going on. When it takes 30 method calls to make a basic web service call for some static data in a DB you're going to want some help figuring out where it went wrong.
Helping you with a language that you don't know that well - The mere presence of auto-complete and param hinting can help out in a big way on this front. Typing at 70-80WPM when intoxicated in a snow storm doesn't help you when you have to Google your way through Microsoft or J2EE documentation to do the simplest things.
Managing complexity - I have to admit. Once your actual code file count grows beyond 20 or so, it's really nice to just be able to right-click something and see where the heck it was defined or rename it 6 different files at once. Especially when working with something you didn't write the bulk of when dealing with a team.
If I'm not wrong and you're at least similar to me in historical outlook on IDEs, I would go with the four things I actually have found them useful for as things to rank the value of an IDE on.