This is only true if your goal is only to speak some language rather than be a linguist.

The analogy is a little off because most people do not much need to be linguists.

But programmers almost always benefit from being a linguist that can pick up any language and do some job and then the next job might be any other language.

The abstract language allows you to see the difference between the universal principles and the arbitrary quirks.

You don't think it's worth the abstract stage it to know that? I do.

Even though I'm not primarily a developer. This is just as an ordinary mere user of computers. Just the plain utility of being even basically literate and functional and do a little coding or modifying in any language that the current project happens to use is extremely valuable in whatever I want to do at any given time.

Not to mention the entirely other obvious thing that you almost always learn a simple version of any new thing rather than starting immediately with the most advanced and complex version.

No, this reasoning does not hold up to scrutiny.

Need-based learning is the way to go with this for sure. Z80 assembly (ZX Spectrum) used to be a popular online recommendation, it's probably a good thing it's no longer popular... On the other hand, I think most people who are casually interested in learning a bit more about assembly don't have a need, so aren't going to actually use it or do anything with it. If the need for any particular system just isn't there, just a weak desire to learn a little, learning fundamentals is a decent strategy, and picking a language that helps get to and express those fundamentals will be helpful even if you later on use a different language. What are the relevant fundamentals for assembly? Maybe just a story about how CPUs from the 70s sort of worked is fine. With spoken languages, there's not much difference in "cleaner" things like Esperanto vs. useful things like English in showcasing fundamentals like nouns and verbs. With assembly, x86 is kind of insane, so I think there are bigger differences.

Of course, some people might consider modern hardware advances to be the fundamentals. Like if you aren't learning about simd and so on, taking into account caches and multi-cores, what's even the point, sort of opinions. I can almost get behind that.

My biased opinion though is that if you want to learn beyond a casual level, you should definitely be learning something that is running on actual hardware, not some sort of emulation layer. x86 then comes back into prominence since most PCs are that. However in the context of a captive audience like students in a classroom, the teacher can decide on something less insane, more fun than things like figuring out how to take an -O0 compiled C file and optimize a loop (ignore -O2 will do it better), and more showcasing a "need" because unlike your x86 class assignment, you can't just trivially do it in a higher level language, and you can't just swap in an x86 chip to a PCB. My first introduction to real assembly in college was with a little PIC microcontroller to control a robot car. I knew a bit of x86 by then, just enough to compare, and it was such a breath of fresh air just to use something not x86. It could have been ARM (we later used an ARM chip to program an RTOS and do other embedded systems relevant stuff), or anything really, the important thing is it was real. In the quest for teaching a "simpler assembly" I know some schools have done things I consider absurd like having students learn some other architecture but can only run code in some provided emulator on Windows, not a real chip with real peripherals you need to write code to talk to.

Comparing spoken language with programming is such a terrible comparison to make. The two even at a fundamental level have almost nothing in common. The brain uses completely different parts for programming and human language.