I always find the most interesting aspect of "we changed from X to Y" to be about why change is happening, how it is managed, etc. Context is everything, but the process described by the OP sounds like standard, top-down decision making. The OP certainly gets to it by the end of the article.

I've gone through this process (tech stack shift), both as a recipient-of-change as well as a catalyst-agent-of-change. Remarking on the email that the OP's CTO sent to everyone, these statements stick out:

  "...A technology choice will be made appropriately for the needs as we see them..."
  "...no hard decision has been made about our future languages or technologies..."
  "...Less C#/.Net, more Scala/Java/Open Source..."

The CTO likely has very good intentions, but this is an implied technical decision that's already been made. He references "we" in the email to imply group participation in decision-making, but it is very much a you-are-with-us-or-you-are-against-us definition. To wit, those who didn't buy in were shown the door.

Having been the guy in that chair, this is not an easy thing to do. Being handcuffed by prior technology decisions is not only difficult, it's often untenable. Usually, the people hired into those leadership roles often have to resolve the decision making issues that got the company to that point. That said, here's what I've learned in terms of how to go about these types of long-term changes:

- As the CTO, take full responsibility for introducing change. This is not taking credit, but instead being the owner of the decision and ensuring it succeeds. Support the team, and encourage them to openly question the decision, so that those questions can be addressed. The CTO's email above makes a change decision requisite, but it's up to everyone else to make it work. To anyone who's worked in a potentially charged environment, that's a typical setup for scapegoating. As the lead dog, don't put your team in that position. If your decision comes off as playing-the-executive card, you have failed.

- As a team member, embrace change but make it completely objective. Be open to change, but only as it helps to reach a goal. Evaluate technologies after using them, comparing them, and finding what's good and what's not-so-good. Make your personal productivity the least-influential point of analysis. If you can't find a way to assess something honestly because of your preference for operation, you're doing yourself a disservice. Be productively critical of technical decisions -- your own, and others.