Naja...Recht haben die da schon. Ihr Fazit ist nicht falsch. Ich halte es aber für unvollständig.

Code, der nicht zu lesen ist, ist meiner Meinung nach definitiv schlechter Code.
Da es auf dieser Seite auch um Hochsprachen geht (Java), stellt sich die Frage nach der Effizienz kaum. Wer weiß schon genau, was der Kompiler da nachher aus dem Code bastelt? Mit sowas wie z.B. statischen Methoden hat man zwar eine begrenzte Möglichkeit, auf Speicherplatz zu optimieren, aber so richtig dolle ist das nicht. Im Prinzip bleibt da als Kriterium nur noch Lesbarkeit. Und das, was Peter schon angesprochen hat. Code, der keine undefinierten Zustände zuläßt.

Assembler finde ich klasse, AVRs programmiere ich damit gerne. Und ja, man kann auch in ASM ganz vorzüglich gut verständlichen Code schreiben. Aber ganz ehrlich-ich bin heilfroh daß es für gewisse Probleme auch objektorientierte Hochsprachen gibt. Wer meint, Klassenprogrammierung sei umständlich, der hat meiner Meinung nach OOP nicht verstanden. Und wen interessiert es, ob auf einem Desktoprechner ein Programm ein oder zwei MB weniger braucht?
Klar, man kann es auch in die Richtung wieder übertreiben und mit irgendeinem MS-Framework eine simple Messagebox auf 200MB aufblasen.

Ich persönlich nehme ja lieber für jedes Problem das passende Werkzeug.