I probably should not have dismissed the concerns as minor. And I view this not as an idiom but as a tool that can sometimes be used. If a class has virtuals (and thus a vtable) and run-time polymorphism then it's probably created on the heap, managed via a smart pointer and probably outlaws assignments anyway. For the cases that don't involve virtuals (much more often than not in my code), calling base class operator= should be OK in practice (although I didn't realize that it's formally UB). Using this trick in both base and derived classes is, of course, very inefficient.
As for exception safety, yes, it's horrible but then again so is a default generated member-wise version (which doesn't always deliver basic-guarantee). If your copy constructor can throw -- don't use it. Hopefully your class has a no-throw swap and copy/swap can be used for copy-assignment and this trick for move-assignment.
Again, this is not meant to be a universal idiom -- just a utility that can be used in places where it's safe. Having said that, maybe the number of gotcha's does outweigh the benefits of ever using that.