Looking at the code with optimization off, is only meaningful when debugging errors in the C code, or you suspect the compiler vendor to have gravely misunderstood a language construct (and not in the code generation).

If you intend to ship a product where the code is built with optimization (size and/or speed) turned on, then it's only meaningful to look at the optimized code. On one hand, you will not know how well the compiler will map different C constructs to the target hardware if you look with optimization turned off - without optimization, the compiler vendor is allowed to produce absolutely lousy code. On the other hand - only if looking at the optimized code will you have a chance to spot potential problems. Without optimization, the generated code may look like every single variable had the volatile keyword.

A big issue here is still that the cost of a chip doesn't naturally follow from the supported clock frequency or amount of flash or RAM. In the end, a chip capable of "wasting" 70% of the time and flash can be cheaper than a chip with optimum size to handle your optimized assembler. And it can draw less current.

This is an old document, but the information is worth reading anyway - you can get quite nice ARM chips for $1.
http://www.bluewatersys.com/docs/whit..._micro.pdf

There is more to it than meets the eye. The customer may like a cheap product with low energy consumption and well-working firmware that has a low maintainance cost. The number of bytes of flash used is most probably not something the customer spends sleepless nights about.