When I was at Michigan Tech I was part of the group that would create an annual version of this, and we were actually running all AI in the same Java process (somewhat sandboxed) which of course led to scalability problems and limited you to JVM languages. For us it didn't matter so much since our target audience was new comp sci students at a school where the starting and most used language was Java.

Our other restriction was that we wanted to support hundreds of units per team, and we wanted tens of thousands of computed turns, but be able to compute that within 3-5 minutes.

We did learn from that naive approach though and the next year I believe it was done with a text based API. If performance were an issue, it could be done with protobuffers, since most popular languages have at least some implementation of them. The year we did the java implementation we had replays the size of 250mb+ due to how much data we had, even with deltas, compression, and other pruning. The text API was only feasible due to a massive reduction in the amount of game entities and turns.

The key thing was when you want to offer API commands. We wanted starting freshman to be able to compete, and that required offering things like pathfinding, predefined list filters, etc. This also mattered since it was run like TopCoder where they only knew about the game the day of the competition and had 8 hours to code an AI for it. The least buggy way to support that in multiple languages is to have the API computation happen on the server, then your language specific APIs are just wrappers around the API calls and data and much easier to change as your game changes.