The problem with most IDEs is that they want to have a certain degree of control on how the project is organized, and this could be a problem if you have to work on that project with other people. In my experience this leads to two series of related problems:
If you start a project in a particular IDE, they will layout for you a particular directory structure, file organization, file naming convention, build system, etc. Of course most of these options are customizable, but it's not always possible to adhere to specific conventions which you might be required to follow. Projects with a complex build system might be difficult to implement from within the IDE. Moreover, the project might not be suitable for external, independent modification; so for instance, if you are planning to write an opensource application, avoid making the IDE a dependency for the project.
If you import a project started elsewhere, chances are it won't be very easy to use all the features provided by the IDE. You will have to figure out how to hook the build system, the debugger (as the binaries might not be where expected), etc. This is especially true for large and complex projects.
The reason why these ares not a problem under Windows is that Visual Studio is a de-facto standard. Under *nix there's a tendency not to impose particular tools/editors when developing a project collaboratively, and this is why these "cross-IDE communication" problems arise.
As a final note, if you learn, say, kdevelop or netbeans, you might have problems if one day you have to work on a machine where installing those is problematic (e.g. you might not have a Java runtime available and you might not be allowed to install it). If you learn (say) Vim + plugins, you are way safer: you can keep your configuration as a .zip file on your webserver and be pretty sure that Vim will always be available everywhere.
