Performance is a topic that I frequently end up discussing, and it's also something that is a core part of my job these days. But perhaps it's a contrarian streak in me that wants to bring up the reasons not to focus on performance, or at least call out tradeoffs - I am generally very weary of "X is good" statements that don't acknowledge some "... at the expense of Y".
As a fun exercise, try going through Wikipedia's list of system quality attributes and see what examples you can come up with.
To make things more interesting, trading off performance to gain productivity in some area might yield enough engineering capacity to work in other, more important areas of performance. So, for example, you might choose a highly productive, very general-purpose tool for the front-end of your systems, then spend the time you gain with that choice into improving the performance of back-end systems which might yield higher scalability overall or lower cost or benefit multiple front-end and partner systems and thus be more leveraged.
I tried to provide multiple examples, but I don't have very many hard-and-fast rules that apply across the board. Instead, I urge engineers to start from understanding the goals for your system and then make decisions within that framework.
Happy tradeoffs!
P.S.: While browsing around for sources of inspiration, I found the Tradeoffs for performance efficiency page on the "Microsoft Azure Well-Architected Framework" site, but I don't think it's very well written. Many of the items there are not tradeoffs as such, but only loosely connected considerations. Which is bit of a shame, because there's some good information through the rest of the guide.
This is particularly galling because Microsoft published excellent guidance as part of the Improving .NET Application Performance and Scalability book many years ago.
P.P.S: Rico Marini is a font of knowledge on this stuff (his MSFT posts are over here).