Why is this limitation important? Doesn't realloc copy anyway? Well, not always. Linux has this neat system call called mremap  that in theory allows an allocation to move in virtual address space but not in physical memory. (To be precise, mremap moves PTEs directly.) Realloc-via-mremap is much more efficient than relloc-via-copying, and it's a shame that limitations in C++ language design prevent our using it, at least with standard containers.
Yes, yes, a move constructor requires both source and destination addresses to be simultaneously valid, so we can't use mremap  in the general case. But lots of C++ objects (like, e.g., int) are trivially movable , and these objects would work just fine in an mremap-based vector.
 well, without the shared mapping dup hack, but that's specialized
The reason for realloc is that often an allocator can extend an existing allocation in place if the next block is free (and this can be done without syscalls). As you described, except for trivially copyable objects though, realloc doesn't really work in C++, so a better allocator interface for C++ would be a try_realloc that would attempt to reallocate in place but do nothing on failure. Unfortunately most system allocators do not provide it  so it is kind of a catch-22 and most proposals never made it into the standard.
 jmalloc does provide xallocx that only reallocates in place though.
glibc malloc switches to mmap for allocations above ~128KB by default, which could be reached by vectors with just a few thousand elements (or a few very large objects). glibc does use mremap to reallocate mmap’d chunks - so in that sense the memory remapping hacks are already present in a general purpose library.