Not specifically C, but you do want to have a language that's as close to the hardware as possible. Since Julius supports way higher resolutions than the original, the time required to draw the screen also increases: full-HD resolution requires 6.75 times more pixels to be drawn than 640x480. I've had to make optimizations to the drawing code to get a decent framerate on higher resolutions.
However, many people in game programming care about their craft and having as much control as possible and also being efficient with their resources. In this project specifically, there might be also some kind of nostalgia thing going on.
By the way, even though I use Python daily for ML and some web stuff, I find Python very lacking for serious, complex projects because of the dynamic type system, bad performance, and the infamous GIL. I find the idea that programming something in a system-level language is some kind of lost, arcane craft that shouldn't even be attempted quite perplexing.
I don't disagree re: the downsides of Python specifically, just threw it out as an example.
> I find the idea that programming something in a system-level language is some kind of lost, arcane craft that shouldn't even be attempted quite perplexing.
Well, some of us are self-taught developers and so system-level languages are very unapproachable.
Ultimately though, seems like a simply unnecessary headache even if one would be competent in using those languages. Friends of mine with CS degrees still don't opt to do side and hobbyist projects in those languages, for example.
The Python type system really has quite a lot of overhead compared to this :P
You could write an emulator for x86 in Python that'd be fast enough to run the original operating system and game on modern equipment.
Whether that would be the best choice for implementing a game like this today - probably not.