During software development we use many tools such as the IDE, code coverage, static analysis and build tools. There exists many of these tools with each their advantages and disadvantages as well with differences regarding personal preference. Being able to work with tools you feel comfortable with is important for your efficiency. Because of this different people might prefer different tools, but how should this be handled when working in a team where having a uniform setup has its own advantages.
First of all we should distinguish two big sets of tools, those that only affect the personal situation and those that are shared. An example of the first is your IDE, which IDE you choose does not affect anybody else in the team. A testing framework is an example of the latter, since your tests will be written using that framework and that code will be shared across the entire team. It is essential that everybody in the team can understand, expand and maintain work that has been done by somebody else.
While it make sense to allow people to work with their own preferred tools as this allows them to work as efficient as possible, not knowing a tool is not an excuse. Of course there is a learning curve and it will take some time to become proficient with it, but in the end you will be able to master it if you try. What is more important is how efficient can someone be with the tool, what features does the tool provide. A user may now be more efficient with a known tool but there may be another tool that will allow him to be even more efficient after he has mastered it.
When settling on a determined tool, it is impossible that everyone will be satisfied with the decision as different people have different preferences. But as with everything in a team, it is all about making compromises and each member of the team will have to be tolerant to other opinions and different ways of working. Of course this can be avoided by letting people select their own tools, but this may result in chaos.
Coming back to the two types of tools identified earlier, the first type is often not a problem to let people decide for themselves, the second type however is more catastrophic as it will settle deep inside of your code and you will have to maintain it. So what may start as everyone selecting their own favorite tool will result in everyone forcing their choices on everyone else.
Personally, I never had any problem with having a complete fixed working environment going from coding standards to IDE. It is just a lot easier and more convenient to make sure everyone has the same setup and something that works on my machine will also work on someone else his machine. Moreover there is a lot more possibility of sharing knowledge and lessons learned, such that other members of the team can learn from others and the effort spent by one member does not go to waste.