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.

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.