OK, to follow up....
I downloaded the 9.3 GB .tif.gz file and it unzipped (un-gz'd, that is...) into an 11 GB .tif file. So, whoever is compressing these files is using different compression ratios for the different files, since the 284 MB file also decompressed into an 11 GB file.
The resulting .tif imports fine into Release 9 (image below).
As to Manifold checking your Windows setup, that can require significant work for applications that leverage Windows like Manifold, where you want all Windows settings to automatically apply and be honored. It's not just running out of disk in the folder where you want to extract or manually write something, it is running out of disk space in places like whatever is the TEMP folder or page/swap space.
It's a performance hit to always be double-checking Windows every time such operational memory is used. In the tradeoff between running slower and simply advising people "make sure you have plenty of free space," in an era where 4 TB disks cost $55, the latter is probably the way to go. :-)
That's not part of the world for limited, client apps like Q or Arc, which don't have the ability to import anything but can only link. They save space with that strategy, but they end up being much slower and also are constrained by whatever can be done in a 1980's format like TIF (speed, for example), aren't portable to different machines just by moving a project file, etc, etc. Link-only packages do simplify storage management, since whatever space the linked file occupies in the folder where it sits is pretty much what it takes.
By the way, it's interesting to see that this is one case where Manifold .map format results in less storage space required than TIF. Importing the 11 GB TIF file into Manifold and saving the project resulted in an only 3.3 GB project.