What do the developers think about using OpenCL or CUDA for the simulation?

Sadly, AMD's drivers are notoriously buggy. In 14.4 (With my stock A10-7850K) I randomly froze on music decoding and web browsing. In 14.7, I had full crashes just by running GPU-Z and major errors running 3dMark (Both worked fine in 14.4). I'll admit its 14.7 Beta and I didn't try the brand new update to it, but holy cow that's bad. It's a powerful chip, to say the least, but it's not at all matured yet (still iffy about trying to overclock it) and the drivers are painful right now.
(Also, I run a 4.8GHz i7, and that's what I'm comparing its power to. It's very impressive for being an APU, and even the GPU is surprisingly good.)

GPU's are just CPU's designed for 1-2 very specific operations:
http://en.wikipedia.org/wiki/Graphics_processing_unit
If all you want to do is those opereations, running them on the GPU is indeed the faster choice.
CPU in turn are a lot better for general purpose calculations. They can't do GPU stuff as fast as GPU's, but they can do a whole ton of stuff GPU are just plain terrible at.

If you are doing graphics processing or video encoding, you are doing those kinds of operations.
In most cases you have to specifically design your code to be effective for that.
Paralell design is one of the areas that cannot be left to a automatic process. It must be implemented by the programmer. It can be made easier/more formalized and thus less likely to cause programmer made issues.
But if a code is not designed with paralelism in mind it cannot be made to run paralell. Trying to do it anyway will only result in Race Condtions and utter chaos.

What you have said is basicly correct. Varrak has stated that he would like to move the particle simulation onto the gpu. He would use compute shaders rather than OpenCL to better fit within the current engines pipline and after instancing for units gets implemented animition work will be partialy done on the gpu as well.

And your also correct in that the bottleneck comes from the planet data and not the unit data. Navigation and collision for such a large surface takes a lot of memory. Sure smaller planets would be able to do just fine. But smaller planets do just fine with the current system anyway. I should note that I have not been including rendering at all here. Just server simulation being sent to a seperate client.

Unless OpenCL-OpenGL(or dx) interop is used, GPU data has to pass through PCI-e bridge to RAM(and game engine sends it back to GPU after everything is complete :/ ).

In below example, I tried to stuff all game logic into OpenCL kernels and is somewhat GPU-bound even though resulting frame pixels is passing through pci-e(even without pipelining(to hide this latency behind game logic GPGPU))



This example does not use interop so has about %15 to %20 latency contribution from PCI-express frame picture transmission(both ways, no pipelining).

Using Vulkan for everything can be much more efficient since there is no OpenCL - OpenGL transitions of contexts in it, unless everything can be hidden behind game logic latency(I don't know if a GPU can concurrently run OpenCL and OpenGL/Vulkan).