misterT, you're hand picking examples that suit your viewpoint, there is nothing scientifically useful in comparison there outside of those two examples to the large field of the efficiency gains that can be had with ASM vs C, with good programmers.
Given equal skill in each language both of a high level, ASM is better period, but it's only as good as it's programmer. C has more flexibility with programmer skill, as the simpler things take less time.
Both you and 3v0 seem to continue to distort what can be done on an equal knowledge basis, 3v0 claims the time to product abilities of C which shouldn't even be considered as this is a comparison between programming language not economics, where he has done the same thing as to show a narrow example where the high gains spoke of for ASM aren't achievable, but that's because of the specific nature of the example, the same as your case of showing a few unfinished projects which look a little sketchy and one that looks polished even if efficiency wise it's a crime against humanity. This has nothing whatsoever to do with ASM vs C, again you're just pulling examples from the net to suit your viewpoint without a critical view of the facts.
I will state a simple thing.
There is no C program that could not be made to run faster using inline assembly given equal knowledge of both languages.
What is sad is that this viewpoint of dislike and ignorance of the power of ASM in a higher level language circles and specifically in production environments.
It's like always throwing a bigger engine in a car when you need more power rather than reducing weight and streamlining it's aerodynamics. Sure no one is going to by an ugly care because it's ultra efficient, but no one is going to buy a 1mpg car either.
Everything I see happening in OS/softare development leans towards a possible complete abandonment of the x86 architecture in favor of RISC (like ARM) or more specifically designed CISC (like video processors) with the addition of dedicated codec chips. C will benefit more from these advents, because it hides the dirty truth that most C libraries are criminally wasteful on a general purpose machine and the hardware itself has to be changed.
IOS and Android started the trend, but Microsofts support of ARM chips for Windows8 blinks an overwhelming light at the fact that you can't just keep increasing processor speed and throwing more code at it to make it work. You can do more with a restructured development environment. It will be absolutely based on C, but the hardware will be designed to be more friendly from a C basis and core routines will still be coded in ASM.
Given this C itself won't go anywhere, but the way it is used will change over time and gradually we'll get back closer towards an only slightly abstracted software layer on hardware that was designed to run the software.
It's not C vs ASM, it's the abstraction from the actual instruction set that makes HLL's less efficient as crap keeps getting piled on them. That's what Microsoft did with Windows7 they streamlined their base code. 8 is going to be interesting to see as it's clear showing that MS wants to continue to support older software but move into the 'now' with truly improved designs.