Rationale (April, 2013):

The design of rvalue references in the language is complex, and CWG felt that an attempt to change the existing rules to accommodate this case ran the risk of breaking other cases. Treating named rvalue reference members as lvalues, consistently with other named rvalue references, is also safer in that it prevents the inadvertent theft of resources from an object to which such a member refers.

According to 7.6.1.5 [expr.ref] paragraph 4,

If E2 is declared to have type “reference to T,” then E1.E2 is an lvalue...

This applies to rvalue reference types as well as to lvalue reference types, based on the rationale from Clause 7 [expr] paragraph 7 that

In general... named rvalue references are treated as lvalues and unnamed rvalue references to objects are treated as xvalues...

Since a non-static data member has a name, it would appear most naturally to fall into the lvalue category. This makes sense as well from the perspective that the target of such a reference does not bear any necessary correlation with the value category of the object expression; in particular, an xvalue object might have an rvalue reference member referring to a different object from which it would be an error to move.

On the other hand, rvalue reference members have limited utility and are likely only to occur as the result of template argument deduction in the context of perfect forwarding, such as using a std::pair to forward values. In such cases, a first or second member of rvalue reference type would be most naturally treated as having the same value category as that of the object expression. The utility of this usage may outweigh the safety considerations that shaped the current policy.