i'm familiar with optimization. i see other people's programs with a different set of eyes -- here's my take:
Usually microoptimization is considered not worth it with the following explanation: it might speed up the program by less that one percent, but noone cares of that minor boost - that's just too little of a change to be noticed.
the funny thing is, one such change leads to 99%. ten such changes make the program noticably faster. for many engineers, changes to their approach of writing a program can make a program execute several times faster. simply being aware of efficiency and writing that way can make your program several times faster without much additional work. such gains are not micro-optimizations, imo.
note: i am never suggesting contextually corner-cutting optimizations in this discussion.
Furthermore, there might be some event handler that fires one thousand times per second and exits very fast - before it is fired again. Noone cares how fast it is - making it faster can't be noted, because it already "as fast as can be observed".
and it's likely already doing more work than necessary since 1kHz is far higher than many cases require. what is this event handler's source, and what are its effects? if it is simply updating the UI and events may be collected and coalesced, then 1kHz dispatch is certainly overkill (far more than 1% - more like 25x). for a system which has mulitple sources and is transmitted in serial, then 1kHz may not be fast enough (e.g. MIDI).
However in mobile devices energy consumption is an important factor. The same event handler optimized to run ten percent faster will lead to less energy consumed and that's longer battery life and a longer operating device. How accurate is the latter judgement about mobile devices? Are there any real life examples that confirm or disprove it?
based on the programs i have seen, there are not very many people considering (or concerned with) such optimizations, even though changing your approach to writing programs can yield incredible gains (>10x or much faster). many that i have seen (in the app development side) just write then take a top down or "hail mary" approach when (/if) performance issues catch up with them. similarly, many will not even take the time to profile until such an occurence. by then, the noise of so many compound inefficencies makes it very difficult to get useful information from a profiler. examples of the hail mary approach would be optimizing the wrong areas (with or without looking for problem areas), or just throwing more cores at problem areas; this happens rather than fixing existing inefficiencies.
for the typical existing program (among the mobile programs i have seen), optimization was not a high concern when it is written. so "yes" they are (in the typical case) worth the time, provided it is in the budget and a priority. in that case, those ten changes which make the program noticably faster can likely be performed in a few hours, and less than a day.
"write lazily and profile in retrospect" as the only action to improve a program is a terrible idea: taking the time to learn how to write an efficient program (as it is written, not by taping it together at the end) is the superior approach (imo); use the right algorithms, forbid wasteful copying, allocations, calculations (+many, many other categories). of course, analyzing performance in retrospect has its merits, but if you write the program to be efficient from the outset you will have a whole new level of efficiency because you learn a lot and consider and evaluate execution from multiple perspectives.
the other thing is that programs should (often) be written for reuse, a poorly written program will introduce changes which may break clients' programs when the inefficiencies are removed (or just remain inefficient to avoid breaking existing programs).
one great benefit of considering it when you write is that you have a very clear idea of how the program will operate (although not a complete picture), you can use this information to aid in the design of the interfaces and how it stores its data. the truth is, an engineer can implement something which is several (e.g. >10x) times faster than the standard "one size fits all" solutions provided with the OS.
finally, it's also worth it beyond mobile devices. there are lot of inefficient programs out there, written with the mindset that hardware will be faster in two years (frequent rationale, even for programs written today!). while that's not incorrect, it's over-optimistic. as well, parallelization has purpose but it is the wrong "default solution" for many programs. many of these existing programs can be best improved by first removing the existing inefficiencies.
so... there are typically a ton of those 1%, 2%, 7% (and much worse) cases in the real world. correcting them or (more importantly) not writing/exposing them in the first place can provide great benefits. many of those cases can be easily located and corrected (provided the engineer has some experience with this). it can, however, really be a pain to correct and re-test after the fact. if a program is to optimal, it will ideally be written that way from the outset.
as an end user, it's irritating to continuously wait for slow programs and to throw twice the hardware at problems created by slow/inefficient programs: Q: "what are you going to do now that you have twice the cores and twice the memory?" A: "regain the responsiveness and productivity i had before i upgraded my software -- that's about it". quite inconsiderate of the developer (imho).