I’m generally in favor of moving the stdlib stubs over to Python eventually and most likely gradually. In fact, I opened an issue about it in the typeshed issue tracker a while back: Thoughts about type hints in the standard library · Issue #5444 · python/typeshed · GitHub
But I consider annotating (parts of) the stdlib and providing type stubs for the stdlib as two separate issues. The former - together with unit tests - serves to ensure the correctness of the stdlib, while the latter serves Python’s users. In my personal experience it’s often better to keep stubs separate from the type annotations in the source code, although some kind of synchronization tool would be useful. Stubs are often quite intricate to best suit the users of an API, but such intricate annotations often hurt readability of the source code - especially when using overloads.
This would be especially true in the case of the stdlib, where fairly well tested - and complicated - stubs already exist in typeshed. Using the annotations from the stubs in the stdlib would probably cause a lot of type conflicts in the beginning. On the other hand, throwing away the existing stubs and using newly added type annotations in the stdlib would be a disservice to users that rely on the advanced annotations in typeshed.