One thing to keep in mind is the issue of portability. It's common to need to develop games library or engine code that will run on a PC (x86), console (PPC for XBox360/PS3/WiiU and x86 for XBone/PS4), mobile (mostly ARM, rarely some x86 or MIPS), and so on. C and its ilk are pretty much as low-level as you can get and still be able to compile your code on a diverse set of CPU architectures.
As a company picking a language for a new project you also have to weigh tools, productivity, and hiring. You can find a lot of people experienced in C++. There are very good tools available for it. The language is decent at allowing a developer to express algorithms directly without worrying about machine details and hence saving time. Other languages do even better in all these area.
If you go with assembly, you have a much smaller pool of developers to hire from. The tools amount to little more than a text editor. Every task is going to involve a lot more time and effort due to the need to explicitly walk the CPU through every non-reusable step of every algorithm.
If you are a company with X time to ship your product and Y dollars to get the job done, you really want a language with a competitive (and hence cheap and plentiful) market, time-saving tools, and good developer productivity.
Making your game faster doesn't make you money. Actually shipping the game within budget does make you money.
Knowledge vs Compilers
A developer who intimately understands the target architecture (the CPU instruction set, architecture, micro-architecture, system buses, peripherals, etc.) can probably write faster code in assembly. The vast majority of developers don't fall into that category, however. A modern C/C++ compiler often has a lot more knowledge about the architecture than most programmers and hence can often generate surprisingly good code (though of course they can still sometimes generate surprisingly bad code).
Keep in mind that modern compilers can employ a number of optimization passes that simply surpass the realm of viability for a human to employ, especially at the project sizes of today's games and on today's highly complex machines and OSes. Various forms of inter-procedural analysis (or whole program analysis) allow the compiler to look at the entire program in ways a human simple can't. They can reason about very complex sets of interactions. They can make decisions with more information than a human can typically deal with at once. This is basic to the trend of all information analysis (look at where data mining has come in recent years as further example). The compiler can often use very advanced and finely tuned heuristics
Observe how many things like the
inline keyword in C++ is treated as a soft hint by most modern compilers. The simple truth is that most human beings, even very experienced ones, are simply terrible at determining when inlining (or other types of optimizations) are actually beneficial or hurtful. The compiler will often ignore the
inline keyword in cases where its logic determines that inlining would be counter-productive. Especially with inter-procedural analysis, the compiler is able to figure out on its own when to inline functions and when not to, or even when to partially inline a function (a technique that vetted assembly programmers might already be aware of, but they're unlikely to know when to use for maximal benefit).
The point is that the core assertion of the book you're linking is simply dated. The compilers then were often dumber and the CPU architectures simpler for humans to deal with, but today we have significantly more capable (and complex) technology.
Others have noted that Rollercoaster Tycoon was possibly the last major game written in assembly, which came out in 1999. That's 14 years ago, a whole 2 years before GPUs and the programmable graphics pipeline (which must be coded in high-level languages if you're sticking with the latest DirectX or OpenGL APIs, I might note, as they've both deprecated and ceased maintaining their assembly syntaxes).
One might look at which games have been written primarily in assembly or which use assembly at all. I will note that not one of the three AAA engines I've dealt with professionally has had even an ounce of assembly; the closest they get is using compiler intrinsics.
I'm not at all big on trying to pretend authoritative opinions are fact, but it's hard to disagree with the lead engineer of Unreal Engine and agree with an academic. Especially when it's hard to find any evidence that backs up said academic. If assembly were more practical, one would expect to see it praised by today's game developers a little bit more.
I wonder if, at this point, [assembly] is at all practical?