"Worth it" needs context, like how much simpler it is to write and read and maintain vs. how much faster it makes something to the user markedly more responsive, interactive, requiring less time for them to wait.
Saving a few pennies to purchase a can of soda won't do me much good if I have to travel a distance to save those pennies, especially given that I rarely ever drink soda these days. Saving a few pennies per can on a purchase of a million can of sodas could be a huge deal.
Meanwhile saving a few pennies when two people are right next to me and one offers the exact same thing for a few pennies cheaper and the other doesn't, and I choose the more expensive one because I like their hat better seems like a foolish case of pessimization.
What I often find people calling "micro-optimizations" seem to be curiously devoid of measurements, and context, and user-end discussion, when there should absolutely be all three to consider such optimizations if they aren't trivial to apply. To me a proper micro-optimization these days relate to things like memory layouts and access patterns, and while they might seem "micro" in focus, they are not micro in effect.
I managed to, not so long ago, reduce an operation down from 24 secs to 25 milliseconds (about 960 times faster), with identical outputs (secured by automated tests), with no change to algorithmic complexity, for volumetric heat diffusion skinning, through "micro-optimizations" (the biggest of which came from a change in memory layout which got it down to about 2 seconds, then the rest were things like SIMD and further analysis of cache misses in VTune and some further rearrangement of memory layout).
Wolfire explains the technique here, and he struggled with the time required:
My implementation managed to be able to do that in milliseconds while he was struggling to get it down to less than a minute:
After I "micro-optimized" it down from 24 secs to 25ms, that was a game-changer in workflow. Now artists can change their rigs in realtime at over 30 FPS without waiting 24 secs every time they made any little change to their rig. And that actually changed the whole design of my software since I no longer needed progress bar and things of this sort, it just all became interactive. So that might be a "micro-optimization" in the sense that all of the improvements came without any improvement to algorithmic complexity, but it was a rather "mega-optimization" in effect that made what was formerly a painful, non-interactive process into a realtime, interactive one which completely changed the way users worked.
Measurement, User-End Requirements, Context
I really liked Robert's comment here and maybe I failed to make the point I wanted:
Well, c'mon. Nobody is going to argue that this kind of change isn't "worth it." You were able to demonstrate a tangible benefit; many so-called micro-optimizations cannot.
This is, in spite of working in a very performance-critical field with often real-time requirements, the only time I consider any micro-optimization which requires going out of my way.
And I'd emphasize not only measurements but the user-end side of it. I'm an oddball in that I came to my current field (and formerly gamedev) as a user/fan first, developer second. So I was never that excited by the usual things that excite programmers like solving technical puzzles; I found them a burden, but would bear through them through the user-end dream I shared with other users. But that helped me to make sure if I was optimizing anything, it'd have a real impact on the users with real benefits. It's my safeguard against micro-optimizing aimlessly.
That is actually as important as the profiler in my opinion, because I had colleagues who did things like micro-optimize subdivision of a cube into a billion facets only to choke on real-world production models like characters and vehicles. Their result was impressive in some "tech demo" sense, but almost useless to actual users, because they were profiling and measuring and benchmarking cases that didn't align with real-world use cases. So it's so important to understand what's important to users first, either by learning to think and use the software like one or collaborating with them (ideally both, but at least collaborate to them). The most important thing to me if we want to get micro and start shaving cycles and cache misses and so forth is to start becoming really good at prioritizing where we go out of way to do that (which naturally corresponds with knowing all the places we shouldn't do that, for which both profiler and user-end understanding are very important).