Yes

I learned z80 assembly back when the cutting edge of technology was a ZX Spectrum, and 68k assembly when I upgraded to an Amiga. That knowledge served me quite well for my early career in industrial automation - it was hard real-time coding on eZ80's and 65c02 processors, but the knowledge transfers.

Back in the day, when input got mapped straight into a memory location and the display output was another memory location, then assembly seems like magic. Read the byte they corresponds to the right-hand middle row of the keyboard, check if a certain bit is set in that byte, therefore a key is held down. Call your subroutine that copies a sequence of bytes into a known location. Boom, pressing a key updates the screen. Awesome.

Modern assembly (x64 and the like) has masses of rules about pointer alignment for the stacks, which you do so often you might as well write a macro for it. Since the OS doesn't let you write system memory any more (a good thing) then you need to make system calls and call library functions to do the same thing. You do that so often that you might as well write a macro for that as well. Boom, now your assembly looks almost exactly like C. Might as well learn that instead.

In fact, that's almost the purpose of C - a more readable, somewhat portable assembly language. Experienced C developers will know which sequence of opcodes they'd expect from any language construction. It's quite a simple mapping in that regard.

It's handy to know a little assembly occasionally, but unless you're writing eg. crypto implementations, which must take the exact same time and power to execute regardless of the input, then it's impractical for almost any purpose nowadays.

Get an 8-bit computer emulator, and learn 6502 or Z-80 assembly.

Usborne machine-code-for-beginners or any book by Rodnay Zaks.

It gets deeper from there, and modern CPUs are kind of awful to hand-hack assembly on, but you'll at least learn how the computer really works!