In the old days programming assembly language was nasty because one mistake could mean your computer had to be rebooted and you lost your work. Not anymore.
If all you want is a basic understanding of how things work, that level is ok. If you want to play/program, it is a completely different story.
I'd even go so far to say: Why do assembly if your goal is not to be better than the compiler, at least in some respect? Beating the compiler, now tell me that it's simple stuff.
Why learn assembly?, well for one, the non-abstract aspect of assembly is less abstract, and arguably easier to understand than even the simplest high level languages. Secondly, learning assembly is also learning how computers work and that paradigm will help you even as you largely work in a high level language.
And beating the compiler isn't as hard as you might think if that becomes necessary some day.
googles Intel CPU data sheet
Ah, here we go.
https://www.intel.com/content/www/us/en/products/docs/proces...
Just two volumes and 1000 pages of reading. Simple!
I've found working with a simpler, smaller processor can be an absolute joy.
Eventually I actually read the first chapter properly and added MOV AH,4CH / MOV AL,0 / INT 21H. When my executable returned to the DOS prompt this time after running it, I felt like my mind had just expanded 10-fold as I realised what had been happening.
And then you wonder what can you think to tell it to do. The wonder of computers.
Then it hits: that crash, bug, unexpected behavior is definitely my fault!
Lol, good times when one works on a routine that executes, crashes and burns long before that finger loses contact with the "return" key!
Anything beyond that gets complex quickly, in one way or another. On simple architectures, like the 6502, even doing a simple division is complex (heck, even additions are verbose, since 8 bits are too few for a lot of operations). On more complex architectures, like x64, there is a monstrous ISA full of inconsistencies.
Learning assembly as in learning an instruction set also doesn't include a lot of details of computer architecture, although at least some modern assembly books mix both domains.
Writing an assembler for 8-bit CPUS like 6502/Z80 was doable; I wrote a 6502 cross assembler (in Z80) so a Z80 development machine could output 6502 in 1985. It got harder with 8086 and 68000 chips.
But you also need to know about calling conventions of your operating system if you want to do any form of system call, which you very likely want to. Which registers supply arguments, which registers have to be saved, addresses of system functions which can change with OS or kernel version. You also need to learn what these function do. How would anyone know that writing a 48 into your accumulator and calling interrupt at address 80 opens a socket on Linux?
Thinking about this again makes assembly seem like a terrible, terrible idea...
To start with I would either recommend x86_64 for either Windows and Linux. I would prefer Linux here but I believe UEFI for example uses the Windows calling conventions, so taking a look at that might be practical. But these combinations usually offer the most learning helpers.
Usually you should only cause general protection faults at worst if you have something newer than a 386. But no guarantee...