Essentially, WordPress needs to connect back to the server where it is actually running on.
There are several possible ways WordPress can use to write files and thus “overwrite” itself during an upgrade. From a security perspective, the important part of this process is that the new files must have the same ownership as the old files.
So, WordPress performs a test first by writing a file directly and checking who the resulting owner is. If the owner matches the PHP files, then it knows it can write files with the correct ownership (this means that the process is “setuid” to the file owner).
If the resulting file is owned by a different user id (which is likely if Apache/PHP is running as a different user, like the “www” or “apache” user), then WordPress has to use a different method to create files with the correct owner.
One approach is simple FTP. If it makes an FTP connection back to the server it is on, then writes files over that, the resulting files will be owned by whoever it logs in as over FTP. So, it prompts the user for FTP information.
But FTP isn’t very secure. So as you have found, another method is via SSH2. Using the SSH library for PHP, it can make an SSH connection back to the server in the same manner. And that is why it needs a private key, because it’s using that to make an outgoing connection back to itself. By making that connection, it can set credentials, and write files as the user who has those credentials.
If you’re concerned about it having those keys, then generate a new set of keys and use those for this purpose exclusively.
To answer your direct question, no, WordPress does not “give” the keys anywhere. It downloads the upgrade package, unpacks it, and then uses those keys to make a connection back to its own server (loopback, basically), and then copies the files over that connection. In so doing, the credentials mean the files get the correct ownership and avoid the security issues of having the WordPress files owned by the main Apache/www/php process.