Github.com is their corporate site, hosts their application, and is how we all interact with repositories (via https or git://). But, the only data you get from that site has been processed through their application and sanitized.
The only way to get access to the raw user-generated data is through raw.githubusercontent.com or Github Pages which hosted on github.io. And the data from raw.githubusercontent.com has the MIME types set so that you don't get HTML rendered -- only the raw plaintext (I think).
So, in this specific example, if there was someone hosting a phishing site in a github account, it would have been active only through github.io, not the main github.com site. (You could have likely seen the source code from the main site, but it would not have actually generated an HTML form).
For historical views, here is the Github blog post that details the change (2013): https://github.blog/2013-04-05-new-github-pages-domain-githu...
https://en.wikipedia.org/wiki/Censorship_of_GitHub
Probably they think that GitHub didn't sanitize the content on github.com well enough.
Or the more expensive option where you use a registrar that gives you get a direct phone number to an account manager.
Here, I uploaded that image from the other day that crashes some phones. I gzipped it so it wouldn't generate a preview, and attached it to a bug. When you click the "github.com" link, it downloads the file, and (at least with my web browser) uncompresses it and opens it with your default application. It's bit-for-bit the same as what I uploaded.
https://github.com/kengruven/strukt-bugs/issues/40
I don't know if this is exploitable. I haven't spent any time trying to break GitHub. This is just something I happened to notice once.
I don't know what that would mean in this type of scenario (phishing) either. I wonder what an html attachment would look like...