Por que as funções-membro do criador de valor não são recomendadas na palestra CppCon 2014 de Herb Sutter (De volta ao básico: Estilo C ++ moderno)?

Na palestra CppCon 2014 de Herb Sutter, Back to Basics: Modern C ++ Style, ele se refere no slide 28 (uma cópia da Web dos slides está aqui) para este padrão:

class employee {
  std::string name_;
public:
  void set_name(std::string name) noexcept { name_ = std::move(name); }
};

Ele diz que isso é problemático porque ao chamar set_name () com um temporário, o noexcept-ness não é forte (ele usa a frase "noexcept-ish").

Agora, tenho usado bastante o padrão acima em meu próprio código C ++ recente, principalmente porque ele me salva digitando duas cópias de set_name () todas as vezes - sim, eu sei que isso pode ser um pouco ineficiente ao forçar a construção de uma cópia sempre, mas ei, sou um digitador preguiçoso. No entanto, a frase de Herb "Este não é o casoproblemático"me preocupa porque não entendi o problema aqui: o operador de atribuição de movimento de std :: string é noexcept, assim como seu destruidor, portanto set_name () acima parece-me garantido noexcept. Eu vejo uma possível exceção lançada pelo compiladorantes set_name () enquanto prepara o parâmetro, mas estou lutando para ver isso como problemático.

Mais adiante, no slide 32, Herb afirma claramente que o exposto acima é um anti-padrão. Alguém pode me explicar por que não escrever código ruim por ser preguiçoso?