What? The instruction set matters very little. Pretty much all games are written in C++ and last time I checked there are C++ compilers targeting pretty much any architecture in existence. The graphics API is more important than the instruction set.
The Cell processor was very different, architecturally. I can easily see games originally designed for the PS3 to require significant effort to port to the 360 and PC. (While the 360 used a PowerPC processor that actually reused assets from the Cell, it was architecturally not that different from typical x86 multicores.)
For video games, the CPU architecture is still very important.
Remember when Halo came out on the Mac, and it was running slow as molasses on higher-performance hardware than what the game was originally written for? That's in part because many of the optimizations that make code run faster on x86 did the opposite on PowerPC. And any code that relied on SIMD instructions would likely have to be rewritten from scratch.
I'm not particularly familiar with the Cell architecture, but based on what I do know I suspect that going between it and x86 would be an even bigger headache.
The graphics API is more important for what? Gameplay? AI? Load times? Physics? Or did you mean rendering triangles, because indeed graphics APIs are very important for that.
I think it is extremely naive to assume that the CPU's underlying architecture and microarchitecture are utterly mundane details abstracted by the C++ compiler, ESPECIALLY in the case of consoles. Consoles are underpowered by today's standards, and making today's game run on them requires a deft maximization of both the GPU and CPU, not a mindset like "well C++ will take care of the CPU stuff". In case you hadn't figured it out, common C/C++ stuff from Havoc Physics to little old memcpy() and strcmp() are all hand-optimized for their platforms -- sometimes multiple implementations that make use of various ISA extensions. Try stepping through them in a debugger sometime.
Surely, /surely/ this is the least of their concerns. Since when did we get so sloppy as to assume byte ordering in files? When was the last time your PNG loader failed on x86 because the file has big-endian fields?
In the console programming world, cycles are precious. You don't tend to waste time doing things 'just in case', you're much more likely to assume a best-case scenario and engineer things that way.
In terms of endianness, it's not a huge problem - the toolchain normally copes with this, as assets are built individually for each target platform. This is what we did last time I worked on a cross-platform game anyway.
