Others have covered the noexcept reasoning above.
Herb spent much more time in the talk on the efficiency aspects. The problem isn’t with allocations, its with unnecessary deallocations. When you copy one std::string into another the copy routine will reuse the allocated storage of the destination string if there’s enough space to hold the data being copied. When doing a move assignment the destination string’s existing storage must be deallocated as it takes over the storage from the source string. The “copy and move” idiom forces the deallocation to always occur, even when you don’t pass a temporary. This is the source of the horrible performance that is demonstrated later in the talk. His advice was to instead take a const ref and if you determine that you need it have an overload for r-value references. This will give you the best of both worlds: copy into existing storage for non-temporaries avoiding the deallocation and move for temporaries where you’re going to pay for a deallocation one way or the other (either the destination deallocates prior to the move or the source deallocates after the copy).
The above doesn’t apply to constructors since there’s no storage in the member variable to deallocate. This is nice since constructors often take more than one argument and if you need to do const ref/r-value ref overloads for each argument you end up with a combinatorial explosion of constructor overloads.
The question now becomes: how many classes are there that reuse storage like std::string when copying? I’m guessing that std::vector does, but outside of that I’m not sure. I do know that I’ve never written a class that reuses storage like this, but I have written a lot of classes that contain strings and vectors. Following Herb’s advice won’t hurt you for classes that don’t reuse storage, you’ll be copying at first with the copying version of the sink function and if you determine that the copying is too much of a performance hit you’ll then make an r-value reference overload to avoid the copy (just as you would for std::string). On the other hand, using “copy-and-move” does have a demonstrated performance hit for std::string and other types that reuse storage, and those types probably see a lot of use in most peoples code. I’m following Herb’s advice for now, but need to think through some of this a bit more before I consider the issue totally settled (there’s probably a blog post that I don’t have time to write lurking in all this).