Back when I got started with computers it was 1982, and the available programming languages were BASIC and Z80 assembly language. A lot of people growing up around that time did assembly language coding, because they needed the speed, or because (like me) they wanted to hack games for either infinite lives, or to ease copying.
Of course assembly language is still used in some areas, it used to be necessary for optimization a lot more than today due to evolving general purpose hardware. But it is still useful for embedded and microcontroller programming.
I don't often touch assembly these days because I have a need for it, but do it for fun because it reminds me of simpler times and fewer abstractions. e.g. a recent project:
(Of course these days with microcode, and complex processors, it's not really bare-metal anymore. Not like it used to be. But try telling kids today that, and they won't believe you !)
I think it's deeper than that. I started coding professionally just before the internet took off. Before that I didn't have much interest in computer networks and seemingly overnight I was dealing with a huge new vocabulary of unfamiliar terminology like "port", "peer", "client/server", "protocol", "router", "bridge", "firewall". This wasn't just academic arcana either: whenever I had a problem, the network types would start asking me to check to see if the "firewall" was blocking my "client" from accessing the "port". I found myself able to muddle through by following their instructions, but I felt like a foreigner in a foreign land whenever anything didn't work the way it was "supposed to".
Web programming documentation wasn't helpful in navigating this territory; it assumed you either knew all this stuff of somebody else was taking care of it for you. One day I decided to start from "the beginning" and read TCP/IP illustrated and within a few chapters it all came together and I found myself able to troubleshoot problems that sometimes even the networking "experts" couldn't resolve.
Learning and understanding assembler is like that: once you understand EXACTLY how a computer works, there's no mystery in whether you coded it wrong or you didn't understand what to expect.
Because there are some engineers perhaps at ARM, Apple,
Microsoft, Intel or Google who deal with compilers or operating systems and UEFI booting devices that you're probably currently running or using to either build software or even reply to this thread, who still take interest in reading about blog posts like this.
> I don't see pursuit of this topic happening in my anecdata of programmers I interact with in day to day life.
Maybe not for you, but it's the reason why you are able to post your message here and browse the web or build software faster thanks to the engineers who did this sort of programming. Sure, general end-users shouldn't care but it's gives me confidence that there are some engineers out there who understand some OS internals to 'make' things happen even at FAANMG companies, rather than doing generic web apps all day long.
P.S. And if a low-level programmer goes into web, stuff like this  happens :-)
Oh right, not everyone is in my field.
> Seeing a program you wrote running directly on the bare metal is deeply satisfying to anyone who enjoys writing software.
This is it. I have been on this site for over a decade now and most the obscure stuff is popular here because it satisfies this criteria for some people. Its actually different for different people. For some its bare metal programming, for some its obscure languages like K, and for even others its some libraries.
Maybe you don't do any of this stuff, but there are plenty of engineers that do this daily.
What kind of dev are you, and what kind of dev do you usually interact with?