Earlier quoted context omitted.
This is answered quite clearly in the linked page. GitHub Pages originally didn't support SSL on custom domains, so people would often put Cloudflare in front of it. Now GHP does support SSL on custom domains, so Cloudflare is no longer needed, but obviously a lot of sites still exist with the original setup.
> GitHub Pages originally didn't support SSL on custom domains, so people would often put Cloudflare in front of it. I've done this myself and I'm fixing it now! (Some JavaScript APIs I've experimented with over the years require HTTPS - from WebAuthn, which hey, fair enough - to Web MIDI, which hey, what the heck? https://developer.mozilla.org/en-US/docs/Web/Security/Secure... )
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...)