For one thing, the selection state is visible to the webpage. For another thing, the webpage is where the text lives. Put that way it sounds funny, but think about it. You have a bunch of content processes, each of which is in charge of loading some number of webpages that the user wants to have open. There is a single UI process that the user can interact with. When the user actually initiates a copy, the UI process doesn’t know what text to put into the clipboard. The text is all in the content process! The UI process merely has to figure out which content process to send the messages to, so that the right text ends up in the clipboard. And that's more complicated than it looks because any given page you are looking at might be stored in multiple processes. A page on domain A with a frame that has content from domain B will often have a different content process for both domains, to ensure maximum separation of state between them.

The bug appears to be a race condition in how the state of which content process has the most recent selection is synchronized with the UI process. The patch at the end of the bug report changes it so that when the user unloads a page no message is sent to delete that state. Instead, only whatever page gets loaded or switched to next will send a message to replace the state. This should eliminate the problem.

Left–over tooltips are a completely different kind of problem.