This seems a lot more like someone deciding on Go up front and then pushing a process through to pick it - it wasn't the fastest in their tests and it was the only language without existing usage at the company, and basically all the qualitative advantages are either not very unique or not quantifiable or both. No other new languages besides Go were even considered, despite some that easily meet the criteria for consideration.
If you forced me to conduct best language olympics, the process I would use might look something like this:
1. Each team develops the same vertical slice of the business in their ecosystem of choice.
2. Test officials will make an edit to each codebase (somehow invisible to git history) that introduces a subtle bug. Alternatively, they may propose a small feature enhancement.
3. Time how long it takes each team to get a corrected/updated build deployed & re-tested successfully.
4. Go to 2 until statisticians are satisfied with the results.
That might be the point. The best tool is often the one that the team knows best. So you might really be testing for the case where the team knows a tool best and thus can respond the fastest to the work request.
So if you're a Java shop you pick Scala because it seems amazing until you read about real world usage/find out for yourself, and then you pick Kotlin.
