Why deal with binary and assembly to create great games? What is the result the programmer get out of performing low level programming on the games?

What do you mean by 'binary'? Do you mean actually entering machine code? No one should be doing that in this day and age.

In the past, handcrafted assembly, inline or linked externally, was often a good option to boost the performance of certain parts of game code. Often, compilers would output instructions that weren't always necessary, or didn't order instructions in an optimal way. Assembly code is essentially a one-to-one translation from source to machine code, so by using it the programmer could craft an optimal set of instructions specific to a task, resulting in performance better than what the compiler output. Over time, as compilers have gotten smarter and CPU architectures have evolved, dropping down to assembly usually isn't going to be beneficial. It's often better to optimize an algorithm than to rewrite it in assembly. Assembly can still useful to take advantage of special instruction sets for specific cases, like SSE to optimize a matrix library. But in general, unless you're working for a team pushing the limits of the hardware and trying to eke out every last ounce of performance from a particular platform, assembly isn't something you need to "make great games",

Being able to read assembly is a valuable skill to have when debugging any kind of system-level software.

Quite a few times I've seen someone exclaiming "Argh, why is my [insert complex C++ code] crashing here", when a veteran swoops in with a hexadecimal memory and assembly code viewer, tracing through the code to point out a now-obvious point of failure....

Not sure what you mean with "binary". Binary file formats (i.e. not text / human-readable file formats) are used for efficiency. I can parse a binary model file in a several microseconds, compared to several milliseconds (or seconds) for an XML file

Also, all of these details -- low-level stuff -- belongs in the inner workings of game engines.

Actual games are often not written in a low-level language, because they don't have to be. Games are often written in "productivity" languages, like Lua or Python or C#, to lessen the required time/budget required to build them.

Only the really performance critical parts (i.e. the engine) are worth spending an excessive amount of time working on. Lower level programming is more verbose and explicit, which lets you ensure that things are occurring in a very precise way (often for performance), but the flip-side is that this requires more time, and more experienced staff.

When you're calculating 10,000 animated transform matrices (an engine task) then that becomes very computationally expensive -- it takes quite a bit of CPU time, which means it has an impact on the FPS counter. This means that you start to care about clock cycles, branch mispredictions and L1 cache behaviour, which are issues that low-level languages allow you to address.

When you're deciding which animation a dozen characters should choose next (a game task) -- this doesn't take a lot of CPU time -- then you don't care about micro-optimizing all those low-level details to gain back an extra nanosecond of time, so you're better off using whatever language makes it easiest to solve the problem in an elegant way.

last time i has to go to the metal was about 1993, assembly code for a real time blitter that did blit, mirror, zoom, and rotate simultaneously. As i recall, this was with Watcom C++, and the target PC was a 386, or was it a 486? it was one routine, about 1 and a half screens of code. the phreaker on the team wrote it in about a week. i spent another week tuning it for max performance.

Well, I should just add that for this discussion I think that C++/C would be considered a lower level language as well, considering that most AAA games/engines are written with it. The reason for this is that you get the control and speed, and moreso the lower you go, with Assembly being the ultimate in control and speed, though as stated above that has changed with the modernization of compilers.

That doesn't mean development speed is faster. A game can usually get created much faster in something like UDK/Unity/Shiva/GameMaker than by programming it in low level languages. But, this assumes that one of those programs/frameworks has the requirements you need for your game, and you know how to use them. For most indie games, that is the case, but for AAA studios, they want/need lower level access to things that most indies just don't need. For example, Unity's scripting as pretty fast, relatively speaking, but it won't be as fast as well coded C++. It will beat badly coded anything though :) Some AAA games really need that speed, for example because they would like to release for as low-grade of hardware as possible, while not loosing any gameplay(which in general many AAA games still suck at).

In reality, for us indies, the best solution is something like Unity or GameMaker most of the time. We don't usually need to lower level speed of C++, rather we need lower development times. Our games aren't going to beat out AAA games in sales, so to survive, we need to make more and more fun games, without spending too long on the art assets required for AAA engines. And then, the creators of Unity and GameMaker are both smart enough to include ways to use external code created outside of the software. The interfaces sometimes are limited, like GameMaker being limited to char* strings and doubles when sending/receiving from DLLS, but from that you can do almost anything, and the same applies to Unity's plugin thingy. So in this end, us indies get the best of both fast development and access to lower level languages.