Debuggers not being trustworthy is a big problem. This is especially true for people working on new game consoles. Whenever a fancy new devkit comes along there are always times when the debugger will outright lie to you about the state of the hardware. Also on new systems you will run across occasional compiler and optimizer bugs. This can require extensive debugging at the assembly level, taking great care to ensure values were not optimized out, or moved to another area, or otherwise behaving in a rational but unexpected way.
It can take a lot of work, and when you finally do get the 'a-ha' moment discovering that it is a debugger or compiler error, you then get the follow-up event of how to work around it.
Hardware bugs. They can happen with bad firmwares, or inconsistent documentation where it really isn't a bug, just an undocumented feature. They happen more often when the processors get very hot. That's exactly what happens during games with compute-intensive processing and gamers with overclocked chips. Several games, like GuildWars, take steps to detect and notify users when it occurs.
These also happen on early firmwares of game consoles. Since they are covered under NDA you don't often hear the horror stories. When you have documentation that says a function does something, and it doesn't do it, you must spend hours trying to figure out if it is your code doing the wrong thing, or if it is the black box doing the wrong thing. Then you wait for the next firmware update and hope your problem is fixed.
As for the general problems, I've seen all kinds of things:
Metaprogramming is just plain painful, don't submit it to the codebase. Not only are there 'gotchas' all over the place, they fail spectacularly on data-driven development. If you need to calculate Fibonacci numbers that are known at runtime, go ahead. Otherwise either create a data table of pre-computed values or compute it at runtime.
Badly formed macros (#define) that include sequence points or don't properly place things in parenthesis, or even worse include complete statements, can be a source of frustration. They are not expanded in the debugger, are not type safe, and just cause extra work. I've spent many hours going through macro bugs.
Nested macros, especially nested macros that build complex structures should be avoided. While it may be nice to have a few macros that convert a long list of labels into an enum, a corresponding string table listing the enum names, and a corresponding automatic registration at game startup, and so on... those macros really are a bad idea. When they are fully debugged and have been used for several years they can be moderately useful, but there is a high cost to making them work correctly.
