The student picking up indentation 'automatically' is a great example of pain being an extremely useful teacher. The pain of getting lost in one's own code leads to a desire to become more organized.
Programming a system adheres to an oral history tradition, where the First generation has suffered the pain of some attribute (henceforth X) of their system. So they build a certain path around it.
The second generation (like the student in the article) is told why attribute X is avoided as a rule, however without the first-hand experience of the pain from attribute X's characteristics meaning is lost.
Finally the third generation is told to avoid X, and can't really explain why anymore.
I disagree with OP on his bullet points of what doesn't matter (and I don't think it follows from the anecdote):
> That indentation is more than an incidental detail.
> That good programming is about following a set of rules.
> That aesthetics matter in code beyond the behavior being implemented.
I'm going to leave indentation aside for the moment, and talk about line length. People do serious research into how line length in text layout affects various aspects of reading: ease of comprehension, perceived ease of reading (not the same thing, apparently[0]).
Breaking up long lines has no effect on program behaviour, but it does have an effect on comprehension. And programming is by and large a team sport, in which any given piece of code is read many more times than it is written.
We think of, say, four-spaces-versus-two-spaces as a matter of preference and a source of silly holy wars. It needn't be only those things, however: on this, I have no convenient research link, but research could be done, and I have never noticed anyone using one-space indentation, suggesting that it isn't a purely arbitrary choice.
So OP's story of his student seems to directly undermine his conclusions: yes, aesthetics DO matter "beyond the behaviour being implemented", and whitespace is more than an incidental detail if you want code to be easier to debug and change. Following rules is hardly the worst way to get a sensible default for code readability - it is rare that there is a set of code-style rules that results in utterly illegible gibberish. There is always the danger of cargo-culting, but that's life.
1. I wasn't claiming to justify the bullet points, just pointing out that teaching rules without justification causes "bundling" and might have implications beyond the narrow thing you're trying to teach.
2. Notice that I said I indent my code. I deliberately chose the phrase "not very important" rather than "not useful". Your links seem to back me up there. The fact that those studies on line length yield equivocal results, might it not suggest that the content of the lines has a larger impact on comprehension? I can agree with you that a few scattered islands in the ocean have land, and still consider you wildly misguided for choosing to explore them rather than the huge continental landmass beyond the ocean.
3. I think most code is utterly illegible gibberish to everyone but the author[1][2]. This isn't directly the fault of code-style rules, but it is caused by the pernicious idea that the code style rules are all you need. Now, nobody actually thinks that, but spending a lot of time talking about superficial details gives the mind a powerful subconscious cue.
Even before I took up programming, I used indentation: on my TODO lists, and outlines of ideas. Using indentation is very obvious when you want to group lines of text and/or express different levels of hierarchy.
Programming a system adheres to an oral history tradition, where the First generation has suffered the pain of some attribute (henceforth X) of their system. So they build a certain path around it.
The second generation (like the student in the article) is told why attribute X is avoided as a rule, however without the first-hand experience of the pain from attribute X's characteristics meaning is lost.
Finally the third generation is told to avoid X, and can't really explain why anymore.