There are always tradeoffs. The discovery that X, Y, Z could be replaced by X required investigation, which is a cost, and then changes to be deployed which disruptions that also have a cost. If the deployment of the optimization doesn't recover the costs, then it ends up not worth it. Usually the cost is recouped because the optimization is discovered once, and then deployed on a large scale; but that is not always the case.
I think considering the cost of change a cost of the optimized version is muddled thinking. It's a cost of deploying the optimized version, but that is only sometimes relevant.
A pure trade-off between efficiency and stability would imply that, were I already running the efficient version, we could buy stability by switching to the less efficient code.
