I've done several embedded projects in the past 5-10 years years. Mostly it's a matter of writing just enough assembly to get things running, and flipping into C when humanly possible because life is short.
Talk to old video game veterans [waves]. We wrote tons of assembly because there wasn't much choice. But these were largely 8-bit processors, the compilers weren't any good and the code space was constrained. But I was talking with a guy recently who said he'd written hundreds of thousands of lines of 68K assembly, and I have no idea why you would do that because 68K C compilers, Pascal compilers, anything compilers were pretty good even back in the benighted 80s. Well, better than assembly.
Of course, once you flip into C you're still not in an environment where you have much of a runtime (I kept having to explain to a contractor why he couldn't do heap operations in an early boot phase, much less expect the results to be addressable later).
Even in a very code-space sensitive project, I started off with a tiny bit of assembly, then made everything more or less functional in C, then went back and hand-coded routines as we needed to get bytes back: http://www.dadhacker.com/blog/?p=1911
My level of fascination with an architecture can be dramatically by the quality of the available tooling. If there's nothing then that's fine, green fields are great fun. But if the tooling sucks (TI and your DSP software, I'm looking at you) or is horridly expensive, then I'm usually going to look for excuses to use something else.
Since you ask, I use lots of assembly level programming for digital audio signal processing. Some ARM instructions offer special DSP specific features like saturation and fractional arithmetic that have no equivalent int C, so it justifies using assembly. Smaller ARM cores without NEON offer some kind of miniature SIMD by operating on two 16-bit or four 8bit numbers, these can speed up things as well. To take full advantage of these it is best to write some portion of code in assembly. I usually wrap a processing sequence into a gcc-style inline assembly macro, this way I can easily compare with a C-only macro and maintain portability, and it saves me from having to deal with the complete instruction set and calling conventions.
I've also been working with DSP processors in audio processing. The only time I've used actual inline assembly was storing stack pointer to measure stack usage.
For saturating arithmetic and other stuff we used compiler intrinsics, which freed us from handling register allocation, stack management etc by hand. On that processor there weren't special instructions for saturating arithmetic but a flag was used instead, the compiler also kept track of that one too.
We did read the assembly result and tweaked C code until assembly looked like what was expected, though.
Technically, assembly is not required for measuring stack: just use regular C address of any local variable/function argument (minus an address of some local variable in main) to have some approximation of stack usage.
Like kabdib, I've done far more reading disassembly than writing it, because for most purposes it's easier to use C as a macro assembler.
I used to work next to someone programming Tilera manycore systems in assembler, because that's a sufficiently weird architecture that you need to do that in order to see any benefit. This is probably why manycore has never really taken off.
I do have to drop little snippets of asm in to code for bare metal stuff, but generally looking at the output of the compiler to see if it and I are on the same page is my main use.
However, as we may well be about to switch our IoT device to ARM from AVR, this might be a useful primer...
I started getting fascinated about computer architecture a while back, but then I saw how dead embedded programming was in my area.