As someone who works in IT Security profession, there are very good reasons that explains the behavior of your senior. The 2 most relevant concepts are
Segregation of Duties
The principal of SOD states that incompatible duties should be done by 2 or more individuals to minimize collusion and security vulnerabilities. Code development (what you currently do) and code release (What you want to do) are incompatible duties in most circumstances. A developer who had access to production could develop code, embed malicious code such as backdoors or logic bombs into legitimate code , and then release the code to production all while remaining undetected. Such activity is extremely risky to the business, and the loss of critical IT resources can be ill afforded by most companies. If the data being worked on is extremely sensitive, business survival could be in question.
The principle of Least Privilege states that a user should only have the minimum privileges necessary to perform one's job duties and no more. This concept is also closely related to CIA triad of security.
Following such practice minimizes the risk of a user abusing IT resources or gaining unuthorized admin / superuser powers over a system, where he or she can do basically anything he or she wanted, such as:
Destroy data - Violation of Integrity and potentially availability
Deny legitimate users access - Violation of Availability
Disclose data to unauthorized parties - Violation of Confidentiality
Your job as a junior developer is to write source code. It does not seem it includes releasing to PROD. Therefore, your senior is following security best practice by denying you the access.
How to make business Case to be made as a backup for emergency changes to PROD
Having said the above, there should be a backup person who can do live releases in the case your senior is unavailable. Business continuity is impacted if only 1 person can do a particular task, a risk important to most reasonable management. Before presenting your case however, you should check the logging systems used for auditing changes to the production environment. If you don't have this, or if you do but its not monitored, or monitored but without a incident response plan to respond to detection of unauthorized changes to production, then there are bigger problems at your company. If you can assure management that emergency change requests made by developers are securely logged so changes can be reviewed, and unauthorized changes traced back to the responsible individual, then your case of being granted access to PROD increases much more. In order for a audit log to be defined as secure, the following characteristics should be met:
Access to the log is kept to the minimum number of users who have the need to know its contents. - Confidentiality
Logs entries are locked upon being committed so subsequent changes cannot modify previously written log entries. - Integrity
A unique user ID is associated for each user who makes a change along with a timestamp to indicate when the change was made. - Nonrepudiation
To further shed some insight into what can happen when access rights are sloppy, take a look into happened with the OP in these two questions:
I made a possible mistake on a live project at work, how to handle this mess?
Written warning from employer for following manager's instruction to deploy bugfix directly to production
As you are still a junior developer, your senior may not have had enough trust in you given the risks of mistakes in live production environment. This should not be taken personally, as your experience will grow with the time spent at your company. It should also be somewhat comforting for you to know that without access, if something were to go wrong, you would not be suspect, given you never could have accessed production, even if you wanted to.