Isn't the reason for them explained in the paragraph immediately following prior to that code? You want the function to do one thing in the event that it is being called from\as an lvalue and something completely different for an rvalue.
It's an optimization thing. If a function is potentially destructive to the object's state, you can overload the same function in 2 ways:
lvalue function: Will do the extra work to preserve the object's state
rvalue function: Can be faster and let the object's state fall to pieces, because it's a temp object anyway.
EDIT:
You want the function to do one thing in the event that it is being called from\as an lvalue and something completely different for an rvalue.
In general... that would be pretty horrible if your code actually did that. People would expect both versions of the function to behave the same (at least from a viewpoint external to the class).
Some people also like to lvalue ref qualify their copy-assignments and other operators that require lvalues in their built-in versions, to avoid the sort of silly code like std::string() = "abc"; that we put up with in C++98.
but yes, the real point is to trash this if you're the rvalue overload.
With an overload for rvalues, the class author can enforce correct semantics.
(either return a copy by value, or disable the function altogether for rvalues): http://coliru.stacked-crooked.com/a/6558e48bbabbecf1