Lu'!
Déjà pour les entités qui ne sont pas destinées à être héritées, sauf cas particuliers dus à l'implémentation, pas de raison d'interdire.
En présence d'héritage, c'est partagé. Mais globalement, je serai plus enclin à la conserver. Si on regarde le profil des fonctions qui peuvent provoquer du mouvement, on va grosso modo avoir :
| T foo();
void foo(T t);
void foo(T&& t);
|
Pour les deux premières, le débutant considéra qu'il n'a pas le droit de le faire puisqu'on a sémantiquement une copie 
. Après, on passe au cas où il commence à s'intéresser au mouvement, et là, il faut apprendre.
Si on doit faire des fonctions dans le genre de celles au dessus, soit on est en train de le faire pour notre classe de base en comportement non polymorphe, soit on est en train de le faire pour un comportement polymorphique.
Dans le premier cas, on doit s'imposer de ne pas exposer de fonctions de ce genre or du code de traitement du type et on se donne déjà pas mal de garanties. Le reste est déjà commun au passage de référence : on ne vide pas une référence reçue.
Dans le second cas, euh, à moins d'être une buse tu sais que tu es en train de violemment te tirer une balle dans le pied puisque tu sais que ça va conduire à du slicing.
Le désavantage certain de l'autoriser c'est clairement qu'on n'a plus de garanties par typage. Mais l'interdire, c'est aussi s'interdire des architectures pratiques où l'on garde les éléments dans des tableaux sans indirection et qu'on s'ajoute à côté un tableau d'indirection plus général pour les comportements polymorphes.
.