Every time Joomla! updates itself it has to delete the files and folders which the new version no longer ships. The list of what has to go is built into Joomla itself; removing them is the last thing its post-update script does.
That clean-up step does not always happen. The post-update script may not run at all, or it may not run to completion. It may be stopped halfway by a PHP timeout or a fatal error. File ownership or permissions on your server may prevent it from deleting anything. Or the site may have been restored from a backup on top of an older copy of itself without deleting the older site's files first — something we warn about in Akeeba Backup's documentation, and something which happens anyway.
Whatever the cause, the result is the same: your site is running a new version of Joomla, but files belonging to the old version are still sitting on your disk.
This is not a tidiness problem. It breaks sites. Joomla ships a backwards compatibility plugin which registers aliases for classes which have been renamed or removed. That only works because the file holding the original class is supposed to have been deleted at the same time the alias was added. When the file is still there, PHP loads the original class, Joomla then asks it to register an alias under a name which is already taken, and the request dies with a fatal error. Depending on which class it is, that can take out your site's front-end, its administrator area, or both.
The button in the Control Panel reads Joomla's own list of obsolete files and folders straight out of its post-update script, checks which of them are still present on your site, and deletes them. It only ever removes what Joomla itself says should no longer be there; it has no list of its own, so it cannot go out of date with respect to your Joomla version.
Clicking the button opens a small window which works through the list in short batches, reloading itself between them so your browser does not time out on a big clean-up. When it is done, the window tells you so and closes itself after three seconds.
If some files or folders are still there and Admin Tools could not delete them, the window stays open and lists them instead. That practically always means the permissions or the ownership of those files stop PHP from touching them. Remove them yourself over FTP, SFTP, or with the file manager your host provides; if you are not sure how, ask your host to do it for you.
Admin Tools deletes these files using plain PHP calls, on purpose, instead of going through Joomla's own filesystem API. Joomla's filesystem classes are themselves part of the Joomla core, and are exactly the kind of thing a half-finished update leaves in an inconsistent state. Using them to clean up the mess they may be part of would be a chicken and egg problem, so we avoid them entirely here.
This feature is available in both Admin Tools Core and Admin Tools Professional. It can also be run on a schedule, or from the command line.
It is worth running this right after any Joomla update which did not go entirely smoothly, and after restoring a backup onto a site which already had files in place.