I think this limitation exists in the current design of enclosing self property wrappers because there currently is no way to support mutation of an enclosing self value type through the static subscript.
Using ReferenceWritableKeyPath allows you to write a setter for the static subscript because it promises that the value being written to has reference semantics. So, the _enclosingInstance parameter doesn't need to be mutable. Since value types don't have reference semantics, you'd have to use WritableKeyPath, but in order to write to that value, you need the enclosing instance parameter to be mutable. However, inout isn't supported on subscript parameters.
I will also say that using inout for the enclosing instance parameter might violate the memory exclusivity issues that the static subscript was aiming to solve (discussed in the original proposal here). I think a general solution to the exclusive access issue might involve a re-think of the design of enclosing self property wrappers.
EDIT: Just to clarify, I'm not 100% sure whether or not passing inout self to the static subscript within the wrapped property setter would violate memory exclusivity.
Because importing Foundation lets you use certain Obj. C runtime methods that can let you send messages to truly private APIs by turning a string into a selector.
However without importing anything, I'm not aware of any equivalent in pure Swift (correct me if I'm wrong please). Use of a private API is a compiler error in Swift.
Note: the underscore in a public Swift API means it's an _unofficial public feature of Swift. This is not a private API that could get your app rejected in review.
I would love to see it become official, even if it's just limited to reference semantics. This is an extremely powerful and useful feature. Sadly I'm under NDA to describe the use-case I worked on but suffice it to say, it's used on a third-partty app used daily by millions.