OSDev.org

C is used even for embedded systems, and assembly only when they have to. As for compiler writing, probably less than 1% of the programmers in the world are engaged in that activity, with even fewer osdev'ing.

No. It's used when optimizing heavily. I don't know whether it's actually done in practice, but graphics programming would be a big field of application.

Which is part of "when they have to". Nobody in their right mind would use assembly for productive software if they didn't have to. It's different for a hobby OS, of course, because there the motivation for choosing it might just be the fun factor - and if it crashes, nobody cares anyway.

But considering all software that is developed today, "Assembly language tends not to be very much used nowadays" seems to be a fair description.

And could indeed be backed up quantitatively as well:

Even a well-known programming language like Lua is not used as much as Assembly. I think these statistics do not tell us a lot: Assembly is often used together with C, as Lua sometimes is with C++. These statistics seem to ignore that fact.

Not really. Rewriting code in assembly would waste a huge amount of resources, and you just end up doing by hand what the compiler already did for you. That's why almost nobody is doing that, except for people targeting special devices (like small microcontrollers where you have to count every byte), OS-developers (for things like flushing the TLB) and people claiming that "real programmers" only use assembly because it's "so superior" to C. When writing commercial software your resources are better invested in optimizing the high-level code.
Trying to beat a compiler at optimizing is tilting at windmills 99,9% of the time. And when it's not, you most likely just introduced a new bug.

It was done once - and everyone agreed to get rid of it. When programmable shader stages first appeared, there was no standardized high-level language to program them, so you had to use vendor-specific assembly languages. It was a pain to program, you had to rewrite the shader programs for different vendors and often even two different GPUs from one vendor couldn't run the same code. Also, manually optimizing the code was horrible, not only because it was error-prone, but also because almost every GPU had different performance-characteristics.
This lead to the creation of HLSL, GLSL and Cg. Of which all are (not coincidentally) based on C-syntax.
And now, with GPGPU being available to almost everyone, the field is dominated by CUDA and OpenCL, utilizing C- and C++-dialects. Afaik NVIDIA added an extension to OpenCL to allow inline-usage of their assembly-dialect, but I have yet to see someone using it.

You've forgotten video and audio manipulation, where the same equation might need to be evaluated for millions of sets of input data, and the compiler is usually too dumb to produce a SIMD interpretation with decent performance.

It's not "heavy" optimization when a single function makes up more than 25% of your program's CPU time.