Because people frequently in English use the abbreviation "auth", which is ambiguous.
If people are too lazy/whatever to use the full word, they are going to be too lazy/whatever to change to a different word entirely.
The only reason to keep using Auth/Auth is because you want to be less easily understood by others. Calling it "renaming" is itself odd to me, if someone said Identity/Permission or Login/Permission, it wouldn't even flag to me as being unusual or non-standard. I'd know exactly what they meant.
Permissions are a subset of authorization.
I see comments stating that, but no examples.
You may find that your user account has permission to read the employee salary database. However, you may not be authorized to read that database by corporate policy because you are not a manager. Perusing that database will still get you in trouble, because you aren't authorized to do so, even though your account had the technical permissions to access it.
You may find that you have permissions to screenshot internal databases and post them on facebook, however since you are not authorized to do so by policy, you will be fired.
Etc.
It's true that there are technical enforcement mechanisms, and corporate policies, but it is false that the former must be called permissions, and the latter must be called authorizations. The policies can easily be called either authorization or permission. It is true that we refer to e.g. Unix file permissions, and a corporate policy is more likely to use "authorization" but this is not a semantic difference--the corporate policy would be correct and binding if it used the word permission.
If a fellow employee asks you "do I have permission to do this?" you must say "no" (or alternately "you're not permitted, even though the computer will not enforce that"). Saying "yes" because there is a technical permission would be a very bad idea.
However, for as long as I've been in the business, those terms refer to different things. That is how it is taught in school, how it is referred to in documentation, how you have to understand them when you write your CISSP, how various governing bodies separate and refer to the ideas, etc.
During an audit, if you are asked for your authorization policy and you give them a list of file permissions, you are failing your audit (well, not really, but you'll probably get a scoff and a condescending clarification of what the auditor wants -- and it is never good when an auditor becomes condescending).
In a professional context, permissions are a specific technical enforcement of an authorization policy.
You have authorization - you are allowed to see the file now, from this machine attached to this network in this geographic location using this type of authentication.
"I have permission to see this file, but I can't access it outside the corporate network" said many people lots of times.
"Leadership gave me permission to view this file, but the computer/network doesn't permit me to do that."
No matter what you do here, there isn't a simple solution. It's complex.