Fassen wir zusammen:
Assembler ist in 99% der Fälle langsamer und unübersichtlicher als C. Weil: 1. Kann fast niemand besser optimieren als ein Compiler. 2. optimiert diese Person dann für wahrscheinlich genau einen CPU-Typ. Ein C-Compiler baut Code der auf vielen CPUs sehr gut funktioniert. 3. wer mal ein 500 Zeilen Assembler Programm gesehen hat, weiß dass man es entweder erst nach Stunden versteht oder 10x so viele Kommentare wie Code drin stehen.
Um das ganze zu relativieren: In C und C++ lässt sich ohne einen Finger krumm zu machen Assembler Code einbinden. D.h. man kann einzelne Schnipsel, von denen man weiß, dass der Compiler hier nicht alles rausholt, eben mal in Assembler schreiben und nahtlos in sein C/C++ Programm einbinden. Denn sobald man Klassen (oder in C dann eben Structs) braucht sieht ein durchschnittlicher Assembler Programmierer alt aus. Da gehört dann schon jahrelange Erfahrung dazu, um den Code gescheit zu strukturieren UND performant zu machen.
C und C++ haben aber noch einen riesigen Vorteil gegenüber den anderen Sprachen: DirectX. Nirgendwo anders lässt sich so einfach DX verwenden.
Zu Java (und teilweise auch C# und .NET): An sich lässt sich hiermit auch sehr gut ein Spiel programmieren. Allerdings ist man dann besonders bei Java auf OpenGL angewiesen, was an für sich überhaupt nicht schlimm sein muss. Insgesamt kann man aber sagen, dass es sich eher weniger lohnt, da das Spiel am Ende plattformunabhängig ist und man so natürlich immer nur den größten gemeinsamen Nenner nutzen kann und genau das schließt unter Linux verdammt viel aus, da der Großteil der Linux Nutzer die freien Treiber benutzt, die aktuell bei OpenGL 2 rumeiern, während unter Windows schon Version 4 verfügbar ist. Dann gibt es natürlich 2 Varianten für Java (ich hab mich damit nicht auseinandergesetzt, also weiß ich auch nicht welche Java wählt): 1. Es werden nur die alten Spezifikationen unterstützt und alle 'neuen' Befehle, werden in mehrere alte zerlegt. Oder 2. in der JVM ist ein Wrapper, der dann z.B. unter Linux die OpenGL4 Befehle live in OpenGL2 umsetzt. Am Ende ärgert man sich auf jeden Fall über die Performance (bei großen Spielen).
Andere Sprachen: Heutzutage gibt es fast in jeder Sprache eine Anbindung an OpenGL, also egal ob man nun C, C++, C#, Java oder auch eine funktionale Sprache wie Haskell nimmt.
Dann gibt's natürlich noch das Thema OpenGL vs. DirectX. An und für sich sehr einfach zu entscheiden: Will man auf ein riesiges (und nebenbei auch sehr sehr gut dokumentiertes) Framework zurückgreifen, mit dem man in sehr wenigen Schritten große Erfolge feiern kann, dann sollte man zu DirectX greifen. OpenGL bietet im Prinzip die selben Möglichkeiten, aber der Weg ist verdammt steinig: Die Dokumentation ist so brauchbar, aber auf keinen Fall so umfangreich und gut wie die von DirectX. Hinzu kommt, dass man viel mehr Wissen über das Geschehen auf der Grafikkarte braucht, um 'schöne Effekte' hinzubekommen. Aber der Wohl größte Kritikpunkt: Wenn man einsteigen will und Beispiele sucht ist das Internet voll von DirectX und für OpenGL findet man eher die LowLevel basics.
Ich will damit keineswegs OpenGL schlecht reden, es hat seine Berechtigung und man kann theoretisch damit mehr und performanter machen, als mit DX. Aber das Ganze kostet viel Zeit (oder man nimmt ein gutes Framework, so wie es DX praktisch gesehen auch ist). Die ganzen großen Spieleentwickler machen es einem schon schwer noch an die große Zukunft von OpenGL als Sprache für Spiele zu glauben
falls ich das überhaupt geschrieben hab. 
