A transitive restriction would definitely be more powerful for asserting correctness, but would also be much more disruptive to the existing ecosystem, and in our judgment, the Core Team didn't think the cost/benefit tradeoff of a transitive restriction made sense for this functionality, especially when there is already a large transition underway for Sendable restrictions coming in Swift 6.
I'm sorry you didn't get more direct engagement during the review. The Core Team did discuss this point, though, and we decided to go with the proposed availability-based syntax for the reasons mentioned—particulary because public discussion in the pitch had already steered the originally-proposed design toward availability. It is a reasonable concern whether this is a stretch of the availability constraint, but the availability syntax already has several uses not directly related to OS availability. You are right that there are looming scalability issues for generalizing versioning across all attributes it's interesting for. (My own thoughts on that are that our existing availability scheme is already struggling to scale for clients such as the standard library that rely heavily on ABI stability and versioning, and we should probably consider an alternative approach to attributes in the implementation source code for managing interface versioning after a certain point.)