I'm coming at this working in areas where there is no performance SLA. When it comes to offline renderers in computer graphics, there is no "satisfactory performance" to users, because they're already dishing out enormous sums of money to distribute computing across clouds and render farms even with the state-of-the-art renderers to output production-quality images and frames for films, e.g.
But I have to say as one working in this domain for many years that any solution which significantly degrades maintainability in favor of efficiency is actually working against the-ever-shifting performance requirements. Because if you can't effectively maintain your solution for years to come as things are shifting under your feet (both in terms of surrounding code and what users expect as competitors keep outperforming each other), then your solution is already working towards obsolescence and in need of wholesale replacement.
I don't see the ultimate purpose of profilers like VTune as a way to make my code run faster. Their ultimate value is to make sure I'm not degrading my productivity to meet ever-escalating performance demands. If I absolutely have to apply some gross-looking micro-optimization, then the profiler, combined with running it against real-world user cases (and not some test case I imagine might be important), makes sure I apply such inevitably gross-looking optimizations very, very judiciously to only the top hotspots that appear as well as very carefully documenting them because I'll inevitably have to revisit and maintain and tweak and change them for the following years to come if that solution remains viable.
And especially if your optimized solution involves more coupling, then I'd really be reluctant to use it. Among the most valuable metric I've come to appreciate in the most performance-critical areas of the codebase is decoupling (as in minimizing the amount of information something needs to work, which likewise minimizes the probability of it requiring changes unless it directly needs changes), because those critical areas significantly multiply the reasons for things to change. Which means the less information something requires to work, the less reasons it has for change, and minimizing the reasons for change is really a huge part of improving productivity in my particular areas of focus because things are going to have to constantly change anyway (we'll become obsolete in a year otherwise), and it helps to get that down to the bare minimum as well as reducing the cost of such changes.
To me the the greatest and most effective solutions I've found are the ones where efficiency and maintainability and productivity are not diametrically opposed to each other. The quest to me is to try to make these concepts as harmonious as one can possibly make it.