A hard truth for developers, but performance often comes last.
We tend to rank performance first because it is objective and measurable. A 5% speed-up. Decreasing average memory utilization by 1 MB. The opportunities to tune performance become even more apparent the longer we work on a project.
For a large class of software, customers care about performance when it is an order of magnitude larger, but not otherwise.
Your performance enhancement might come at the cost of less apparent benefits like interoperability, usability, or developer experience. Optimization is fragile. It might not change the overall time or cost of the workflow because another parallel step takes longer – i.e., it might not be a limiting step. Switching costs might outweigh performance increases. Path dependence is an overwhelmingly strong force (see QWERTY/Dvorak).
Of course, for low-level libraries, performance often is the product. But, even then, protocols don't always win because of performance (working code is often better than a draft by a standards committee).