If I may respectfully disagree with some of the ideas in the article:
I don't agree with the implied premise that knowing assembly makes you a better programmer. It's entirely possible to write complete garbage in assembly as it is in the latest language from Redmond, You just have to hit the reset button more often.
A better expression of the idea might be "Writing code on a dinky 2kb machine with a 1Mhz processor will teach you how to truly code efficiently, whatever language you use."
I know, I've been there! When Intel's chips opened up the flat memory space and got rid of the 64k segmented model, well... An entire new world opened up for me, at least.
And please don't get me wrong... I love assembly. My favorite technique (when it's useful, for anything I want to move fast) is to prototype in my own stripped-down version of C++ and then once I have the bugs worked out then re-write in assembler.
At the same time, sometimes it's not worth it. Put it this way... I'll not write my own RDBMS when I can just write a select statement in someone else's version of SQL. Perhaps I could write something faster, but A) that's doubtful at best, and B) I'd spend more time in writing it than I'd likely save in executing it within my expected lifespan. Nuts to that!
What I *DO* agree with is that understanding the underlying code does make you think about optimization, although I wonder how much so with current languages.
A Q-sort is a Q-sort, no matter what it's written in. I don't know that being able to write it in assembler is going to make that much difference if you're bound to writing it in say... Java.