Excuse me if I jump here with a not-quite-about-Swift rant.
In Obj-C, there isn't really anything that could be called a "weak" or a "strong" property. The property value (in this case) is a reference to an object, and there's no such thing as a weak or strong reference. It is variables (storage locations) that are weak or strong, not references (pointer values).
Unfortunately, people rely on their intuitions and still think there are weak and strong references, and this contaminates even discussions about Swift.
The significance of "weak" or "strong" on an Obj-C property is that it affects what kind of instance variable the compiler generates if it synthesizes the property — that is to say, if the property is what Swift would call a stored property.
This is only controversial — there was a long discussion about this on the old cocoa-dev list years ago —because some people insisted that calling an Obj-C property "weak" or "strong" is a kind of API contract — that the underlying implementation really does not or really does keep an owning reference to the object, somewhere in its dark interior, and that clients of the class are allowed to make decisions based on this supposed contract.
However, this is all truly an implementation detail, and (IMO) a bad one because of the confusion it engendered in the Obj-C world.
Having said all that, I think @jrose is still correct, that we can't change this in Swift — for @objc protocol methods — for potential source compatibility reasons, though not for functional reasons. This is a case where Swift has to continue to be a little bit broken because (IMO) Obj-C is.