My old job had a lot of embedded programming - hard real-time Z80 programming, for processors like Z800s and eZ80s to control industrial devices. Actually quite pleasant languages to do bit-twiddling in, and it's great to be able to step through the debugger and see that what the CPU is running is literally your source code, opcode by opcode.

Back when a computers were very simple things - I'm thinking a ZX Spectrum, where you can read directly from the input ports and write directly into the framebuffer, no OS in your way just code, then assembly made a lot of sense, was even fun. On modem computers, it is not so fun:

x64 is just a fucking mess
you cannot just read and write what you want, the kernel won't let you. So you're going to be spending a lot of your time calling system routines.
99% of your code will just be arranging data to suit the calling convention of your OS, and doing pointless busywork like stack pointer alignment. Writing some macros to do it for you makes your code look like C. Might as well just use C, in that case.

Writing assembly makes some sense sometimes - required for embedded, you might be writing something very security conscious where timing is essential, or you might be lining up some data for vectorisation where higher-level languages don't have the constructs to get it right - but these are very small bits of code. You would be mad to consider "making the whole apple pie" in assembly.