to remove unused files from the file server use the blcli Delete commands (cleanupFileServer or performFullCleanup). check w/ support about running cleanup because there were issues w/ cleanup in 7.3 and 7.4.1 I think.
In the future, you should 'symlink' or 'softlink' when you create blpackages that deploy hotfixes, otherwise you will make copies of the binary for the new package.
also, if multiple roles are uploading patches and they cannot see the other's patches, there will be duplicates, so you could look at restructuring RBAC such that there is some kind of sharing for downloading patches.
Normally, you should point the payload repository location of all your patch catalogs (if you have more than one) to the same directory on your file server, precisely to avoid duplicating files. This where the actual physical payload (the .exe or .msu) will reside.
When patches are created as depot objects, they always soft-link the file and reference it from that file server's payload location, so it's not possible to have actual duplicates.
What you may see however, is duplicated metadata (the xml that defines the blpackage) that is created during a patch remediation job, becuase you can have multiple blpackages referencing the same patch, but that shouldn't include a hard copy of the payload file, only a reference of its location.
What DOES happen however, is that even though depot objects (patches) are removed form the catalog when you run the Remove Irrelevant Patches action on the catalog, the associated payload file is NOT removed from the file server physically, only the database portion is removed. This means you may have several gigs worth of orphan files in your payload repository location. To resolve this, you'll need o run a custom NSH script job that BMC can provide you. Bill wrote a script for us to do this and we cleared over 30G with it.
The blpackages and installables folders should be automatically cleaned by the cleanup scripts/jobs that are documented in docs.bmc.com (search for database cleanup). These folders are not where the patch payloads (from patch catalogs) are kept however. The installables folder contains files from packages that were uploaded from the console I believe, and the blpackages one contains references to other objects. If the blpackage is soft-linking a file, it won't be in the blpackage's metadata directory, but it it's hard-linking it then it will.