That may be true, but suggesting this means you could just as well write everything in python or some other 'simple language' just doesn't make any sense. First of all because they all introduce their own unique set of problems (e.g. no type safety, much less static, compile-time checking, the need for a runtime, etc), second, because the way people typically use them promote programming styles that are inefficient in ways far beyond some constant-time compiler optimizations (using dict or list for everything, for example, or having no concept of data locality and cache-friendliness), and third, because it's perfectly possible to write C/C++ code that is efficient enough, readable, and easy to maintain. I agree that most of the time the performance of the most obvious implementation of some part of a program is more than sufficient, but to me that just proves the point the problem is not with compiled languages like C/C++, as you can use 'readable, maintainable' as the default way to implement things, and only drop back to obscure tricks if you really need to (which is rarely).

I don't really get the point the article is trying to get across anyway. I don't care about the complexity of the compiler at all, and 99.99999% of the time I don't care about what the assembly it spews out looks like. I'm just using the compiler as a tool, I don't need or want to know how difficult it was to get it to compile my code. The only thing I care about is that it produces valid code, and that the code gets a speedup when I compile with optimization enabled. That's about the extent of my interest in the compiler, and modern compilers have served me very well over the years. Why complain that they need to be complex to produce faster code?