I'm actually of the very opposite mindset. The easiest way to end up micro-tuning a codebase needlessly for hours and far away from real-world user-end operations is to obsess over benchmarks.
You can end up having a performance test slow down to take twice the time and then waste hours with the team looking into and tuning it again when, in the context of the application, the small functionality being tested only takes 0.01% of the time, making trying to speed it back up again a worthless endeavor.
I actually prefer to keep a codebase's performance rather "organic", as in not trying to cement it down with endless benchmarks. At the very least, if you're going to add performance tests to your system, make sure they're high-level enough and close enough to what your users actually do with the software and frequently. I actually don't think an automated build system misses much by omitting performance tests outright as long as there are unit/integration tests for correctness, and I work in performance-critical areas.
My former company made all these performance tests for things so far removed from user end operations, like just timing how long it takes to call a function in a low-level interface a million times over, and obsessing about some performance fluctuations to those areas is counter-productive compared to actually profiling the application against a real-world use case. It even got to the point where people were wasting countless man-hours investigating slowdowns to low-level performance tests while the high-level user-end operations of the application were getting perceivably faster... still the developers were obsessed that fetching a value out of property took 30% more time than when they started even though that had very little bearing on the user. I would have much rather had them profile the application than these micro-benchmarks.
Hotspots tend to shift around to rare cases as things get more efficient in the common case execution paths, and in that former experience, so many developers wasted needless time and energy trying to optimize rare cases by obsessing over these teeny performance tests. Just as important as measuring, if not more, is thoroughly understanding how the software is commonly used. Otherwise we could be measuring/benchmarking and tuning the wrong things and, in worst case scenarios, actually making what users actually do most often less efficient in the process.
To me the real litmus test of whether you're spending your optimization time productively is if you're actually measuring real-world use cases that the users of the software commonly apply and not taking stabs in the dark (at least measuring). Typically the most counter-productive in this regard are the ones most divorced from the user-end side of things, failing to understand the appeal and common case use scenarios among the users of the software.
That said, I think "micro-optimization" is more over-used than profiling. If, by "micro", that means an optimization with no impact on the user, then even substantial algorithmic improvements should be considered "micro", but that's not how it's typically used. Often "micro" is used interchangeably with "counter-productive", when some of the most fruitful and productive optimizations don't come from algorithmic breakthroughs so much as practical algorithms that apply effective micro-optimizations (ex: improved locality of reference). I don't really care if it's algorithmic or low-level tuning of how bits and bytes are laid out in memory or multithreading or SIMD. All that should matter is if makes a real difference, and not to a minuscule function in the system infrequently called, but to the actual user of the software.
