If a performance improvement has no dependencies on other trackers in a stable, ie it cherry picks cleanly and works, then I think they should automatically be expected to be backported in the same way as a bug would be.

The work for the dev and for the reviewers and integrator is near zero so there is little cost to everyone.

If I'm a site admin, upgrading only because of security issues it is a little bit like a 'stick' in that if you don't do it bad things could happen.

Normal functional bug fixes are 'carrots' rather than sticks, you look forward to them and want them, they give you a reason to do patch upgrades.

Performance improvements are the same if not more so: they are 100% carrot and you want to get your hands on them and you shouldn't need to wait a year or two for a major upgrade to get them.

Or stated another way: performance is a feature, and if it is slow it should be treated as a bug in that feature. Even if the bug only manifests at a certain scale or in specific conditions it is still a bug from the end users point of view.

To be doubly clear I'm only talking about 'safe' performance things. If something is re-architected to be faster that is different and more risky and could be master only. I'm talking about things along the lines of a new DB index, an sql tweak, adding a trivial cache, avoiding a redirect, cache control headers for CDN's. Some judgement will be needed.