Understanding this fact does not strictly imply having a basic understanding of memory, but it gets pretty close to it. I would personally be weary of some who calls itself a programmer or software engineer and couldn't write this article themselves.

The only relevant parts is that (1) they are immutable and (2) they are compared by value.

  var a = 1
  var b = 2

Understanding the implementation details is valuable, but I'm not sure why you think it's necessary to program?

If "a = b + c" takes a second to execute, you have to take that into account. The programs that people wrote for 1950s computers were very different from today, even though the language semantics might be essentially the same.

On the other hand, this discussion is helping me understand why the web development world is full of weird database-backed Rube Goldberg machines that can spend milliseconds to access a few bytes of data that were already in RAM.

But it doesn't, so you don't.

Sure understanding performance is necessary to build more complex or higher usage systems, but not understanding it does not preclude "useful programming".

But it doesn't, so you don't.

How do you know it doesn't? What if assigning to 'a' writes to a remote database and waits for the write to be confirmed?

More to the point, how does a new programmer know that is not the case? The average person's expectation of computation speed is shaped by the experience of using server-side web apps: you click on a button, a new page is loaded from the server taking multiple seconds to finish.

To understand that an assignment doesn't run that slow, you need to be told that. Surely explaining local memory would be part of that.

Not really. You just try it, and notice it ran instantly. You don't really have to care how it happens to run behind the scenes, as long as you have a working model of the semantics. That's the entire point of most abstractions, to make it so that you don't have to think about all the details when you don't want/need to.