Games were once written in machine language, because they had exotic hardware for which there was no compiler. The hardware also lacked features that C programmers take for granted, such as efficient 16-bit integer math.
Once games settled on familiar hardware, C compilers became available and in a short time all games were written in C.
C++ seemed like a good idea at one time, and most games are C++ today, but engineers are now mumbling about a return to C, and that might actually happen. I would love to work on a game in C, and so would many coworkers. There's no feature new to C++ that I think improves games.
It would seem now that computers are 1000x faster than a few years ago, a high level language would reduce development time ($) making C obsolete.
This has not happened because game buyers know that the hardware is 1000x better, and want to trade their dollars for a game that looks and sounds 1000x better. This removes the slack from the system that a high level language would consume.
Performance requirements in games are brutal. A new frame of graphics must be rendered in under 33ms (or 16ms!) without fail. Everything the hardware does must be accounted for, so that this budget can be met. Any language that goes off and does something with the hardware that the programmer doesn't understand or expect is going to make it very hard to meet this budget. This is an automatic minus against anything high-level.
Game programmers not only work in a low-level language, but they shun high-level data structures and algorithms too. Games typically don't have linked lists and seldom have trees. There is a movement towards avoiding pointers whenever possible*. Any algorithm with more than O(N) time or O(1) space tends not to find wide use.
*If a pointer doesn't cause a cache miss, then why spend 32 bits to store it? If a pointer does cause a cache miss, best get rid of that cache miss.