I strongly recommend keeping the same set of tools, language and build. Each different element adds overhead. With a small group you can't afford additional overhead.

It is likely that everyone will have to handle multiple aspects of the project. You will want multiple people who can wrangle the build and the tools the better.If everyone is sharing the process then it is easier for the team to be flexible and make the best use of the individual. It also means a relatively experience set of developers. Look for people who have shown flexible and wide variety of interest.

A clear process is also critical. Whatever system you use make it clear how decisions are made. Code review or pair program is required. You don't want to rely on one person to develop a critical system and then find out it is a mess or that no one else is clear on the mechanism.

Poor health can contribute to or directly relate to mental illness. Some in the study probably suffered from other illness but were not diagnosed. It must be just fraction of the measurement but it might be an important one.

A number of reasons
1) Basic human compassion
2) Mentally ill and drug abusers affect the healthy. Drug crime is rampant with a high cost to society. Even if all drugs were legalized, as I believe they should be, there would be still a heavy price, just as with alcoholism. These would include car crashes, unemployment, failed businesses, etc that you mention.
3) As someone with depression, it seems worth fixing.
4) Mental illness is just that, an illness.Why do you draw a distinction between cancer and mental illness. How is someone with cancer "healthy"?

Yet another thing to be depressed about...

For enrolling in health benefits (not Obamacare as it happens), managing my bank statement, etc, I use Internet Explorer. Not because I trust Microsoft, but because I know the provider is going to focus on making their application work correctly with IE. I don't want some subtle discrepancy in browser behavior to route my transaction to underspace. I don't care if it is Microsoft who is not following the standard, they are the de facto standard for most of these services.

The first thing is to figure out what is the communication goals of colleagues.
- Is the boss concerned about status and schedule? Then do go into technical detail, but provide enough information to give confidence in your response.
- Are you being asked to provide a lot of directions and solutions from colleagues or subordinates? Then you can ask for opinions and suggestion before providing other feedback. Once people realize that they should think before asking, you will get a lot less frivolous questions.
- Are you being asked for technical detail? Figure out what kind of information would be helpful for you. Bear in mind some people may want more or less because of experience level or personal style.

Second, don't be too concerned about "needless conversation". Communication is a key to any organization as well as social harmony.

Third, look for, and implement, more formalized systems of information sharing. The bigger the company and the project the more communication is needed. The conversations requirements will become exponential if it is not systematized. A simple example are kanbans in an agile development process. When a story is put into the "ready for development" all the coders know they can take up the story and that the story description and test criteria are written. There is no asking around about what to do next and fewer questions about what needs to get done. Obviously no system is perfect, and conversation will still be required. However, ready access to the information each person needs for the job will reduce lots of unnecessary conversation. There will be less conversation used just to gather information and fewer discussions pointlessly trying to figure out why critical information was not communicated. Conversation can then be more focused on decision making, design, etc which will be a better use of everyone's time.