The LOC, the Internet Archive, and the UK National Archives don't benefit from proprietary compilers for proprietary operating systems like SuperCard; their remit is to preserve these files for centuries or millennia, not until the next update of macOS X. If SuperCard interprets a HyperCard stack differently than original HyperCard did, or SuperCard on a new version of macOS X displays or behaves differently than it did on the previous version, that's a failure of digital preservation. Unless, that is, you notice --- and to notice, you need to emulate the original HyperCard environment and/or be sufficiently familiar with the semantics of the file specification. If https://news.ycombinator.com/item?id=29555959 is to be believed, SuperCard is 32-bit-only and so will not run on the most recent version of macOS X, which lack 32-bit support, which if true demonstrates the enormity of the problem.
As for streams of bytes, a disk is a stream of bytes, or rather a collection of fixed-size blocks of bytes. HFS is looking at flattened HFS files that have been "squished" to fit on a medium that does not, itself, implement HFS. Therefore anything that you can represent with an HFS dual-fork file can also be represented losslessly in a stream of bytes. (You do of course benefit from understanding the dual-fork structure.) HFS+ actually went further, implementing files with an arbitrary number of forks, like sections in ELF or PE. As GeekyBear points out, NTFS did the same, leading to path traversal vulnerabilities in early Microsoft web servers.