In Pragmatic Thinking and Learning, Andy Hunt comments about the difference between experts and novices as it related to standards and tools: Novices don't really care and having a standard helps. Experts know their tools well. While a novice can select the refactor->move method context menu, an expert in IDEA will enter the shortcut (F6) in order to get to the interesting work more quickly. The same IDEA expert will still know to refactor a method if they are using another tool. It will just take more time.
When trying to decide what tool is best, we're often inclined to confuse familiar with better. It's in the interests of everyone on the team to be cautious of this tendency.
Closely related to standard IDEs is the question of how quickly and reliably one can set up a new environment. Organizing your setup around a standard IDE seems easiest, as the IDE settings can be versioned, but that isn't always the best approach, as we'll discuss next.
The Build's the Thing
Regardless of whether or not the members of your team use one or many IDEs, integrated development environments and their configurations are not identical to the build scripts that teams use to run their integration builds. In Java environments, classpaths may differ, and working directories for the IDE may be different than the build environment's defaults. In some cases, differences in the compiler mechanism may lead to different results that vary from the build. These differences are acceptable, as long as they are understood and treat the build script as the canonical definition of "it works."
How, you ask, do you reconcile the requirements that you be able to create (IDE) workspaces quickly and also maintain the fidelity of the build? There are a few approaches. The simplest one is to maintain two sets of configuration files: the build and the IDE configuration. Perhaps one person maintains the IDE settings and another for each IDE, then the files are kept in sync if there is an issue. This means duplication and manual work. Fans of lean software development will see duplication as waste. Fans of any process will see a manual step as a place where errors can creep in. Another, better, way is to generate the IDE build related settings from the build files and not version the build files (with one exception). Many modern Java IDEs for example, can use generate their configurations from Maven or Ant build files.
There are also Maven plugins to generate IDE configurations from Maven build files. Keep the build files as a primary artifact and generate the derived artifact that is the IDE configuration.
The nature of how teams work with IDEs may lead toward workspace configurations and configuration approaches that differ from those that make the most sense in a production environment. One useful aspect of IDEs is that they are customizable to fit the working style of the person using them. In many cases, individual customizations are not suitable for everyone on the team, but that may not matter.
Performance, Individuality, and Agility
In agile teams, people tend to work more collaboratively, in shared physical spaces, and in tighter cycles than on a traditional project. Having similar environments may be more important than in other environments. An Agile team using pair programming could potentially benefit most from a common tool set. A natural question in the context of Agile teams is whether pair programming requires that the team standardize on tool set. If any environment would require standardization, pair programming would, as there are many perceived efficiencies in moving between developers' workstations, as if they were identical environments.
While in practice, some pair-programming teams do standardize on IDEs, many others don't require a single IDE. If you are following the Driver/Navigator model for pair programming, you use whatever IDE the driver prefers. The second half of the pair will quickly pick up enough of how the IDE works to perform basic tasks. Even if you are trading the keyboard freely, the differences between environments still allows for basic collaboration and the diversity of IDEs provides a chance for team members to learn about other tools and provides a path for learning and improvement.
This raises a basic question about the tradeoffs between delivering value quickly as a team and allowing individuals to work in the way that is best for them. Agile methods value individuals, so it stands to reason that, unless there is a very good reason for mandating a tool over one which a productive team member sees a strong advantage, one should allow for flexibility.