If you'd really read the opinions "bashing" the article, you should find that the attitude problem does not lie with us. (Had the title of the article been "Modern programmers should include more assembly in their code", more people would have agreed wit him.)
It appears that both the author and you do not understand the origin of all the problems you've mentioned (e.g. bloatware, bugs).
They stem from:
1. Reality. Programmers don't get to set deadlines and decide whether a software is in a state to be released or not. Managers do. And as a rule of thumb, the latter does not listen to the former.
2. Poor/ lousy/ (add your negative adjective here) programming. If you can write a 1MB+ bloatware in C, Pascal, (add your language here), etc., chances are you will do so in assembly too (or maybe you won't be able to get it working at all). The "bloat" part of the software is not added by the compiler, it's added by the programmer. Same for bugs.
Assembly language has such a bad rep not because people are lazy or ignorant, but because it's not efficient to the *programmer*. No amount of advances can make it as easy to code and maintain as a higher-level language. C (or C++) is often considered to be the lower limit, because at this level, it maintains "human readability" even in large projects and yet I can be reasonably sure that the compiler will do a good job if I write my code properly. Why learn assembly if I can spend half the time and effort in C and the compiler can then do a better job than if I had written in assembly? OK, so even the best compilers have their blind spots but overall they shouldn't be worse than the average programmer in churning out code. (BTW, I used to learn assembly, and have learnt quite a bit about optimizing assembly code by playing around with compilers.)
In fact, the same argument can be applied to learning about machine architectures, since there are so many different models in use (you said so yourself) and the compilers are likely to be just as capable (or incapable) of optimizing code across so many platforms. Be aware that there are more than just performance to be considered here, there are other things like portability, security, compatibility. In addition, external influence is not limited to the CPU, the operating system and settings, HDD speed, multi-tasking/multi-threading can all affect your software in good and bad ways. If you'd really tried, you'll find that it's much harder than you think to attain a speed increase of "even" 2-3x in large projects by simply switching to and optimizing code in assembly.
(And BTW, you're not implying that MS Word is an example of "time-critical, large data-intensive projects", are you?)