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.
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.
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.
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.