I think this needs some elaboration.
The issue is not that it is "primarily an Apple platform concern" - it is that it is exclusively meaningful for engineers creating Apple's SDK libraries. In that respect, it could not be more different to the availability system.
Joe Programmer, writing code which will run on an Apple platform, needs to know about availability. They may need to conditionalise calling certain APIs using if #available, or annotate their own APIs with @available if they absolutely depend on an availability-limited platform API.
Joe will never have to write @backDeploy. He has no meaningful way to use that feature, because there is no chance whatsoever that code compiled against a newer interface will load an older version of his library at runtime. That is a problem that only Apple's SDK engineers need to worry about.
In fact, does Joe even care that a function was introduced in iOS 16 but must be emitted in to his binary if he targets iOS 15? I don't think so! All Joe needs to know is that the function requires at least iOS 15, and whether that calls a copy emitted in his binary or a copy already present on the system is none of his business (the same way he doesn't care about @_alwaysEmitIntoClient today). IMO, things like Xcode's generated interfaces should display the effective availability - the availability context which callers (like Joe) need to ensure before using the function, regardless of where it is physically located.
So Joe should never see the @backDeploy attribute at all, anywhere. He should never write it, and he should never have to read it. It is an implementation detail of the SDK, expressing a distinction that only Apple's SDK engineers need to worry about. For everybody else, it is entirely meaningless. That's the issue.
But you may say, "well, there's no harm in it. Why not stabilise this feature now?"
Once this becomes a formal part of the language, changes must go through swift-evolution. If Apple's internal needs change, for whatever reason, and they need to make additions to this attribute, that will need pitches, proposals, reviews, and all of that. All future language features will also need to consider how they interact with @backDeploy.
And if Apple's SDK engineers find some part of this attribute's behaviour undesirable and in need of adjustment, that then becomes a source-breaking change! Even though Apple's SDK libraries contain the only source code that should be using it, they will need to consider the "other users" of this attribute, who won't really exist.
Stability is a burden. Not, like, in life/in general (although....), but at least in this case. This is an implementation detail of Apple's SDKs, Apple is a very large organisation deploying code to many different platforms of all shapes and sizes, and it is a reasonable expectation that their deployment needs and back-deployment abilities may change with time.
Unless I am mistaken, the interfaces in Apple's SDKs are not guaranteed to work with any compiler except the one that ships as part of the SDK. If this were not a formal language feature, Apple's SDK engineers would be free to make additions or breaking changes to this attribute at any moment, as their needs determine, and those changes roll out in a new version of the SDK with a new compiler that supports them. And nobody else needs to care.
I can't understand why Apple's engineers would sacrifice that flexibility - for what?
So yeah, I think this needs some elaboration. As far as I can tell, making this a formal language feature would be undesirable for all parties. Why does the language workgroup disagree?