Because git is designed to be decentralised. You can push and pull changes to your coworkers' laptops, merge everything, and then push it to a centralised place like Github. Great for when you work at an office with limited internet connectivity or develop your code across multiple mirrors (gitlab + github, for example).
Consider the way the Linux kernel is developed. Change sets are committed and emailed back and forth, and eventually merged. The merged git repository is the official, released source code, but before that change sets are just (attachments to) emails. Then, at some point, someone pushes the changes to Github, containing thousands of merges from tons of people.
Git was designed to work this way, and cryptographic signatures solve the problems that can arise from allowing random change sets. You can sign the commits themselves, as well as the pushes (although signed pushes aren't as universally supported by version control software).
Yes, so GitHub showing the individual commit's email addresses and not replacing it with the name of an associated GitHub account wouldn't work ... because?
Because it doesn't solve anything without validation of email ownership. It doesn't matter if the commit says "Jen-Hsun Huang" or "ceo@nvidia.com". The commit usually contains both (in the "name <email>" format) and both can be spoofed just as easily. The name associated with the email address of a Github account is actually harder to spoof because it requires creating an account with said email.
If people think "the" Linus Torvalds committed something just because they have a github account with the name Linus Torvalds, they're fools. Names aren't unique identifiers and they shouldn't be regarded as such.
There is something to be said got displaying the name and email address for signed commits on Github, to prevent creating an account and impersonating someone who actually signs their commits. In the default configuration, many version control systems will just add a "verified" badge to a commit if the email address of the signature matches an account with the same email address. That protection is obviously useless for unsigned commits, because there's no way to trust the author anyway, but for verified commits a clear indication of which email address created the commit makes sense. Alternatively, the github user account name could be used, of course, if such an account exists.
If you really want to find out the email address of the person who committed something, you can clone the repo and look at the git log manually, I suppose. I think hiding it was done to prevent shitty scrapers from collecting email addresses.
The difference though is, that this is about an existing commit. You can't change the mail address of the first commit to the git/git repository retroactively.
Consider the way the Linux kernel is developed. Change sets are committed and emailed back and forth, and eventually merged. The merged git repository is the official, released source code, but before that change sets are just (attachments to) emails. Then, at some point, someone pushes the changes to Github, containing thousands of merges from tons of people.
Git was designed to work this way, and cryptographic signatures solve the problems that can arise from allowing random change sets. You can sign the commits themselves, as well as the pushes (although signed pushes aren't as universally supported by version control software).