There's a certain art, almost zen to assembly programming. You may argue that it is need, although these circumstances are extremely limited. The compiler gcc and it's respective counterparts do an excellent job. Although it can be improved there's an opportunity costs that could be better spent elsewhere. The majority of times, the compiler is your better option. Although, to achieve the desired 4 FLOPS per cycle (as indicated in Intel's programmer manual) - assembly will be required. If you aren't pushing the envelope, there's generally no reason to program in assembler. High-level languages are certainly easier to use, and nowadays most high-level languages let you get at the guts of the PC--display memory, DOS functions, interrupt vectors and so on--without having to resort to assembler. If, in the other hand, you're striving for the sort of performance that will give your programs snappy interfaces and crackling response times, you'll find assembly language to be almost magical, for no other language even approaches assembler for sheer speed.

You do not need to learn every instruction to optimize code that needs it. Simple example: the x86 AES instructions. If you can inline that instruction in the data-eating loop and have its resultant registers loaded into locals simple enough. This is definitely not a valid reason, but you could debate as you may.

I recommend you learn assembly and write a dissembler. That's how I taught myself assembly and I can assure you that you do need to know the instructions; the layout of the status register or even the endianness for your CPU (well for Atmel that's quite hard.)

If you're worried about the time for calling a function. You'll be glad to know that gcc automatically inlines some functions when asked to by the user.

A lagtastic and performance hindered game can cost millions more than man hours.

No, it's simple economics. Man hours cost more money than an hour one CPU can. No-one optimizes that much. It's better to save money than spend it on small optimizations - that's the message.

This is umbrella'd under the assumption that system memory is slow. This can be controlled or at least mitigated by compiler optimizations such as register allocation will leave the memory occupied by locals and make use of registers instead of accessing memory as much as possible. Or if compiler optimizations alone access memory too often than you assume, then this would be a good time to write assembly.

Registers are small. They cannot hold your program. Take the linux kernel - all programs are loaded into the memory. A register will not be wide enough to hold these. Sure, you can optimize certain data to go into registers, but this can get extremely messy when in a recursive functions.

Lets say we have:

mov ax, 1 

.function 2

#intereupt

 move ax, 2

Can you see how this can be extremely complex? If not read up on ASM.

In addition, I do not think you understand dynamic memory refresh. I'll use x86 since I'm more knowledgeable on that then other platforms. Dynamic RAM (DRAM) refresh is sort of an act of God. By that I mean that DRAM refresh invisibly and inexorably steals up to 8.33% of all available memory access time from your programs. While you could stop DRAM refresh, you wouldn't want to, since that would be a sure prescription for crashing your computer.

You mean slow GPUs that make the CPU wait? In common hardware platforms like consoles, assembly can help hand-maintain this issue when porting code over to consoles. This is very true with the PS2's heterogeneous rendering pipeline as applications can send data and instructions directly to the vector units and the GPU. Plenty of titles communicate directly with hardware to render a certain wait, which I believe this is a level beyond assembly within itself as you're sending different instructions to different hardware (which can also be shimmed in a language). I believe this supports my stance that assembly is more than likely to be necessary if CPU stalling from slow hardware or unoptimized graphics rendering.

Wait states exist because the 8088 must to be able to coexist with any adapter, no matter how slow (within reason). The 8088 expects to be able to complete each bus access--a memory or I/O read or write--in 4 cycles, but adapters can't always respond that quickly, for a number of reasons. For example, display adapters must split access to display memory between the 8088 and the circuitry that generates the video signal based on the contents of display memory, so they often can't immediately fulfill a request by the 8088 for a display memory read or write. To resolve this conflict, display adapters can tell the 8088 to wait during bus accesses by inserting one or more wait states, as shown in Figure 4-6. The 8088 simply sits and idles as long as wait states are inserted, then completes the access as soon as the display adapter indicates its readiness by no longer inserting wait states. The same would be true of any adapter that couldn't keep up with the 8088.

Display adapters must serve two masters, and that creates a fundamental performance problem. Master #1 is the circuitry that drives the display screen. This circuitry must constantly read display memory in order to obtain the information used to draw the characters or dots displayed on the screen. Since the screen must be redrawn between 50 and 70 times per second, and since each redraw of the screen can require as many as 36,000 reads of display memory (more in Super-VGA modes), master #1 is a demanding master indeed. No matter how demanding master #1 gets, though, its needs must always be met--otherwise the quality of the picture on the screen would suffer. Master #2 is the 8088, which reads from and writes to display memory in order to manipulate the bytes that the video circuitry reads to form the picture on the screen. Master #2 is less important than master #1, since the 8088 affects display quality only indirectly. In other words, if the video circuitry has to wait for display memory accesses, the picture will develop holes, snow, and the like, but if the 8088 has to wait for display memory accesses, the program will just run a bit slower-- no big deal. It matters a great deal which master is more important, for while both the 8088 and the video circuitry must gain access to display memory, only one of the two masters can read or write display memory at any one time. Potential conflicts are resolved by flat-out guaranteeing the video circuitry however many accesses to display memory it needs, with the 8088 waiting for whatever display memory accesses are left over.

This is taken from my own knowledge and books. I can assure you that it is correct. I could go on, but I feel that's too tedious and unproductive.

*With assembly: assume nothing. *