Thank you for the links! That makes is so much easier to troubleshoot the problem.
Okay, the files I downloaded from those links are single-file, dual-fork, Carbonized CFM applications. Or, in plain English, they're a Carbonized application that should be able to run either natively in OS X or in OS 9, or if desired, forced to run in the Classic environment by checking the "Open in Classic environment" box in the Get Info window.
Since the application is a single file, it has the file type of 'APPL', a creator code of 'STi0', and a filename extension of '.sea'. The file should be listed as an "Application", and there shouldn't be an "Open With:" section appearing in the Get Info window for it.
Why Aladdin/Allume chose to use a filename extension of ".sea" I'm not sure, as technically, since it's a single file with an 'APPL' file type, the file need not have any extension at all to work as an application.
A combination of discarding the already downloaded files, updating to the latest version of Stuffit Expander, discarding any older versions of Stuffit, rebuiding the Launch Services database properly, disabling the "com.apple.LaunchServices.plist" file, and redownloading the files should solve the problem.
It would be best to discard the files you already have, since if you've attempted to do anything to the "Open With" section of the Get Info window for the file, it alters the file by adding an 'usro' resource to the resource fork. That addition may cause the file to be treated differently after everything else is done.
Since you mentioned you already tried rebuilding the Launch Services database which didn't solve the problem, I wonder if you might want to try updating to the latest version of Stuffit. Either version 9.x or 10.x ought to be sufficient--it's just the earlier versions that I'm not sure about. The reason for this is that the information that populates the LS database is extracted directly from the applications on your Mac, so if there were any problems with the document-to-application information in the older versions of Stuffit, a rebuild in and of itself wouldn't fix the problem.
I'm not sure how Tiger Cache Cleaner will rebuild the database, but a couple of key things should happen in order for the rebuild to be what I would consider "properly done". First of all, the Finder makes extensive use of the LS database, and most likely keeps some form of it cached in its RAM. As you work with the Finder, and for example, drag a new application to your /Applications/ folder, it updates the LS information in its cached version. Then, periodically, it will save this updated LS information to the cache file on the disk. When you issue a rebuild command using the "lsregister" command-line tool, it will rebuild the cache file on disk. If the Finder is running, however, it could at a later time overwrite the cleaned LS file on disk with the information it has cached in its RAM. For that reason, the Finder should not be running while the rebuild is performed. After the rebuild is complete, you should really restart your Mac to make sure that any other applications that were relying on the LS database file by reading it into memory, will be using the proper version. I've written an AppleScript that will rebuild the LS database in this fashion, which you can get at
http://homepage.mac.com/mdouma46/images/LaunchServicesDatabaseRebuild.zip (.zip, ~ 8 KB).
After the rebuild but before you restart, disable the following preference file which keeps track of any custom document-to-application bindings:
/Users/~/Library/Preferences/com.apple.LaunchServices.plist
Then restart and redownload the files and hopefully they should appear properly.
Hope this helps....
Dual 2.7 GHz PowerPC G5 w/ 2.5 GB RAM Mac OS X (10.4.3) 
