Your link gave me a warning that the certificate was only for github domains. This one redirects to kaitai.io but doesn't warn.
I remember having trying to read a decade-old stash of floppies a few years ago. Too many were unusable. CDs are much better but also relatively unreliable. My USB drives fared much better, even the 64 Mb one with the kangaroo logo still works.
For digital media in particular, the Internet Archive is pretty zealously ripping older media .
 A few interesting examples of the sorts of problems that preservationists encounter in dealing with pre-digital formats can be seen here: https://www.nyu.edu/tisch/preservation/program/05fall/physic...
I still have a very old 1x SCSI CD drive (the kind that not many people will remember, using a caddy-cartridge for the CD) on a computer dedicated to "recover" old CD's and the success rate is much higher than on modern CD/DVD readers.
I would say 9 out of 10 with the SCSI drive vs. 6/10 on a modern CD/DVD drive.
Burned CD's are a lot worse. How much worse depends a lot on quality and type of disc, in my experience. If you cheaped out on CD-R's by buying the no-name 50 pack spindles back in the early 00's, those will likely all be unreadable now. The fancy gold Kodaks might have survived, though.
I also collect music CD's and it's getting to be a problem that there's a lot of obscure music (demos, live recordings, etc) that only exists on CD-R, and in very limited quantities. I do have rare demos by local bands etc. that have started skipping just because of the CD-R media aging.
Double-density 3,5" media like the disks for your ST are much better, and both 360K and 1.2M 5,25" types have proven quite resilient in comparison. I play a lot with retro computers in my spare time and anecdotally I find that a random 5,25" 360K disk from 1985 is much more likely to be readable than a 1.44M one from 1995.
I have no idea where to put this thing, but we virtualized the entire thing years ago and spin up the VM when required.
Ugh, I hate software that does this. If you're creating an obscure proprietary format for your files, the least you can do is support it.
Just covering every popular RISC/Unix platform would be daunting. Ever hear of Pyramid Osx? It was once popular. That's skipping over mainframes (not just IBM either, see https://en.m.wikipedia.org/wiki/BUNCH), mid-range (os/400, mpe, VMS, Tandem), OS/2, BeOS, embedded platforms, and much, much, more.
Unfortunately UDFR and GDFR have fizzled out (a theme that occurs sometwhat often when projects have high ambitions and inadequate support). PRONOM is still around, but has difficulty adding in accurate information since the overlap between the technologists with the domain expertise necessary for such a database to succeed and librarians is quite small. It would benefit quite greatly from an infusion of engineers who wouldn't mind filling out forms with corrections. :)
We had one-click solutions for COBOL to C, Java to C#, VB to Angular, etc. Once you have the parsers and generators the work for each project after that is minimal.
For game file formats you may want Xentax (http://forum.xentax.com/) or the "fork" Zenhax (https://zenhax.com/)
Open some files in a hex editor and have a look. Run "strings". Investigate and learn.
I can see other ways you could do that generically for every door game:
1. Run the game in local mode inside a DOSBox running under WASM in a webpage.
2. Run a classic BBS software in DOSBox using nullmodem and a virtual FOSSIL driver and have a telnet server listen and redirect connections to BBS nodes (you'd need multiple nodes). There seem to be already classic telnet BBSs doing exactly that.
3. Run a more modern BBS software like Synchronet on a modern OS and shell out to DOSBox with a nullmodem connection (and possibly a FOSSIL driver) every time someone creates a connection.
Options 2 and 3 are much more computationally expensive, but they will gave you proper multiplayer if you share folders correctly between the nodes.
I think it’s a piece of history that really deserves preserving.