Typed throws are just as an important carriers of static type information as things like classes. What you are saying is equivalent to saying "class instances should not be allowed to have a specific class type in resilient libraries and should always be AnyObject". This is obviously very wrong. The possibility of accidentally locking oneself into a specific error type and then regretting it after a major version release is not a language problem, it's an engineering incompetence problem. The author should just take the precaution to design their error type with future expansion in mind (e.g. a struct with optional metadata instead of a bare enum).
While we're on the topic:
Same goes for anonymous union types (A | B) which are nothing more than syntactic sugar around certain generic enums (e.g. Either<A, B>). This is nothing new and Swift is already perfectly capable of expressing this kind of type, so the "commonly rejected proposal due to compiler complexity" that I keep hearing is also obviously very wrong.
Conclusion:
The type system must be as expressive as the engineer sees fit to make their code expressive. Just because someone can't think of a reason to retain static type information (be that by using a specific error type or using an anonymous union type), doesn't mean there is no reason.