It is a bug in libc++ that cannot be immediately fixed because it would break ABI. Apparently, it is a conforming implementation, although obviously it is often suboptimal.
It’s not clear exactly why the Clang devs made such an implementation choice in the first place (although maybe if you’re really lucky, someone from Clang will show up and answer this question). It may simply have to do with the fact that Clang’s strategy avoids having to have a “vtable” entry for move construction, and thus simplifies the implementation. Also, as I wrote elsewhere, the Clang implementation only uses SOO if the callable is nothrow-copy-constructible in the first place, so it will never use SOO for things that have to allocate from the heap (like a struct that contains a std::vector) so it will never copy such things upon move construction*. That means the practical effect of the cases where it does copy instead of moving is limited (although it will certainly still cause degraded performance in some cases, such as with std::shared_ptr, where a copy operation must use atomic instructions and a move operation is almost free).
* OK, there is a caveat here: if you use the allocator-extended move constructor, and the provided allocator is unequal to the one from the source object, you force the libc++ implementation to perform a copy, since, in the case of unequal allocators, it can’t just take ownership of the pointer to the out-of-line callable held by the source object. However, you shouldn’t use the allocator-extended move constructor anyway; allocator support was removed in C++17 because implementations had various issues with it.