Web MIDI isn't for playing .mid files in the browser. It's for letting in-browser JavaScript talk to arbitrary hardware devices that speak the MIDI protocol; this includes not only things like keyboards and synthesizers, but also stage lighting systems and other theatrical devices that use MIDI as a control protocol (so that you can have, e.g., lighting and sound cues happen in sync, because they're all centrally controlled by a single computer). In general, any API that controls hardware counts as security-sensitive; you don't want MITMs to be able to hijack your hardware devices and make them do something bad.
The major browser vendors committed to all genuinely new features being Secure context only. Secure context means either HTTPS or the local machine.
If the feature is something you could do with a polyfill anyway then it's not really a new feature, it usually makes no sense to restrict it. But something like Web MIDI you clearly can't build with a polyfill, so restricting that makes sense.
The reason to do this for new features is that by definition if your HTTP site already works, it didn't use them, if it relied on features that didn't exist it didn't work. So this prevents backsliding, your HTTPS site might stop working if you downgrade it to HTTP, but your 1997 HTTP site still works since obviously that doesn't use Web MIDI, or indeed probably CSS.
For a few features, vendors are going back and removing Insecure Context support, but this work is slow because inevitably even if it was a terrible idea people relied on it working (e.g. EME is used extensively from HTTP, because you know you really care that people can't pirate your mediocre training video, but you don't care enough to prevent them trivially intercepting it during download...)
If it didn't, then whenever you visited a non-HTTPS site, an MITM could inject code into the page that turns your webcam on and then spies on you. Permission prompts help somewhat with this, but not really enough, given that the address bar provides no clue that you're not talking to who you think you are (beyond the generic "Not secure" warning that users usually ignore since it's so common). Allowing this would be a total disaster for user privacy.
GitHub Pages also doesn’t (yet) support custom headers and you can add them with Cf via Workers. So if you’re concerned about the results of securityheaders.io, for example, you can add those in.
