Almost all Cocoa for any system UI stuff with plenty of Carbon thrown in here and there as needed for other things like QT. I try to replace Carbon code as Apple comes up with more/better Cocoa for equivalent functionality. 100% daily dosage of C for the actual game code and OGL and OAL for graphics and sound. No Cocoa or Carbon is allowed past my timer callback, so I guess I can't really say I use either for the actual game.

Cocoa, Carbon and SDL!!!
Well, I don't use Cocoa for games directly, but SDL uses it internally. I usually don't use Carbon, but for my entry on CreateMacGames latest contest I had to use speech synthesis and, as usual, while it was easier to set up and use on Cocoa, Carbon let's you control a lot of things not implemented in the Cocoa wrapper (like, for instance, the speed & pitch of the synth. voice).

Now, if I ever make a game wich requires a heavy GUI, Cocoa is the right choice.

For most games, you'll be using very little of either. They each have their specific ups and downs as far as games go. Personally, I'm not a fan of AGL, so I tend to go with Cocoa, but I wouldn't say that either is necessarily a better choice.

Of course, as soon as you need a standard Mac OS widget, Cocoa wins hands-down.

The poll is pretty borked. Carbon and Cocoa are not exclusive of each other (au contraire!), and most of the time you will use some parts of Carbon, even if you are coding in Obj-C. Also, just because some API is in C, it doesn't mean it's part of Carbon (QT, OpenGL, for example).

Carbon also contains a lot of stuff for which object-orientation doesn't work well enough to create a Cocoa wrapper.

Cocoa is dependent on the Obj-C language, and vice versa. Cocoa & Obj-C provide a very good object-oriented environment, if OO is your kind of tea. Also, Cocoa has a more advantageous learning curve than Carbon, but in the end you can do the same thing with either API.