This restriction is not strictly necessary but I do think it can help with clarity of intent. We have found over time that allowing API owners to omit availability entirely from public declarations in library modules is a nuisance because it's too easy to forget to add availability to new APIs when it is necessary to do so for correctness. We have other tooling approaches that can address that, though.
That's right, although it's not that useful to add @backDeploy to functions in non-SDK libraries today, it could become useful in more contexts in the future if the scope of Swift's availability model expands.