Sometimes you just have algorithms that can't be better than linear time for which there's still a strong performance demand.
An example is video processing where you can't make an image/frame brighter as a basic example without looping through every pixel (well, I suppose you can with some kind of hierarchical structure indicating properties inherited by children which ultimately descend down into image tiles for leaf nodes, but then you'd defer a higher cost of looping through every pixel to the renderer and the code would probably be harder to maintain than even the most micro-optimized image filter).
There's lot of cases like that in my field. I tend to be doing more linear-complexity loops that have to touch everything or read everything than ones that benefit from any kind of sophisticated data structure or algorithm. There's no work that can be skipped when everything has to be touched. So at that point if you're inevitably dealing with linear complexity, you have to make the work done per iteration cheaper and cheaper.
So in my case the most important and common optimizations are often data representations and memory layouts, multithreading, and SIMD (typically in this order with data representation being the most important, as it affects the ability to do the latter two). I'm not running into so many problems that get solved by trees, hash tables, sorting algorithms, and things of that sort. My daily code is more in the vein of, "for each thing, do something."
Of course it's another case to talk about when optimizations are necessary (and more importantly, when they aren't), micro or algorithmic. But in my particular case, if a critical execution path needs optimization, the 10x+ speed gains are often achieved by micro-level optimizations like multithreading, SIMD, and rearranging memory layouts and access patterns for improved locality of reference. It's not so often that I get to, say, replace a bubble sort with an introsort or a radix sort or quadratic-complexity collision detection with a BVH so much as find hotspots that, say, benefit from hot/cold field splitting.
Now in my case my field is so performance-critical (raytracing, physics engines, etc) that a slow but perfectly correct raytracer that takes 10 hours to render an image is often considered as useless or more than a fast one which is completely interactive but outputs the ugliest images with rays leaking everywhere due to the lack of watertight ray/tri intersection. Speed is arguably the primary quality metric of such software, arguably even more than correctness to some point (since "correctness" is a fuzzy idea with raytracing since everything is approximating, so long as it's not crashing or anything like that). And when that's the case, if I don't think about efficiency upfront, I find I have to actually change the code at the most expensive design level to handle more efficient designs. So if I don't think sufficiently about efficiency upfront when designing something like a raytracer or physics engine, chances are that I might have to rewrite the entire damned thing before it can be considered useful enough in production and by the actual users, not by the engineers.
Gaming is another field similar to mine. Doesn't matter how correct your game logic is or how maintainable and brilliantly engineered your codebase is if your game runs at 1 frame per second like a slideshow. In certain fields the lack of speed could actually render the application useless to its users. Unlike games, there's no "good enough" metric in areas like raytracing. The users always want more speed, and the industrial competition is predominantly in seeking faster solutions. It'll never be good enough until it's real-time, at which point games will be using path tracers. And then it probably still won't be good enough for VFX, since then the artists might want to load billions of polygons and have particle simulations with self-collision among billions of particles at 30+ FPS.
Now if it's of any comfort, in spite of that I still write around 90% of the code in a scripting language (Lua) with no concerns about performance whatsoever. But I have an unusually large amount of code that does actually need to loop through millions to billions of things, and when you're looping through millions to billions of things, you do start to notice an epic difference between naive single-threaded code that invokes a cache miss with every iteration vs. say, vectorized code running in parallel accessing contiguous blocks where no irrelevant data is loaded into a cache line.