At times it may be a better approach to copy an object rather than instantiating a new object altogether. Specially in case where object creation is intensive and take some significant resources to get a new object, in such cases creating a new object by copying it could be more efficient than instantiating again.
The another major advantage is that you can still create the new objects without knowing it's type. Along with this your object creation complexities would be abstracted from the client who want to create a new object and use it.
Language may provide built in capabilities to make the clone of an object. Yet, at time clone objects could be complicated if you have to implement it on your own of handle any corner cases.
One practical example can be taken from video games, let's say that you are playing a car racing game where cars appear randomly on the track. Now creation of car object can be very complex given the level of details some of these games have and if you have to use them as soon as possible the best way could be that all the possible car models are instantiated when the game is loaded and now during the runtime you can create copies far more quick then instantiating multiple such objects or even one big and complex object.
The whole point is that the client would be provide an object whose creation is abstracted from the client, yet client will have capabilities to create more of these without instantiating the new objects.
If you compare this with Singleton the difference could be that second time when we instantiate instead of sending the previously create copy as in case of Singleton in prototype pattern you will clone it and return.
Whereas this cloning can also be completely up to the client to implement it, but that could be complicated stuff to do and you would have to expose some details for object construction to the clients (we don't want to do that rather we want to abstract it), hence the best place for having the logic of cloning would be the class itself.