Teaching juniors to care about software quality and software maintainability is hugely important in order to encourage an overall improvement within the software dev industry.
As I've gained more experience I've realized that maintaining a code base is like any relationship with conflict -- you have to pick your battles carefully or everything turns into a fight / falls apart.
I'm not saying to down tools and get on the war path with management, but to rather try to balance accepting whatever you are told and never coming up for air, versus sitting back for a time to analyse the situation and identify potential improvements.
Ultimately it comes down to the individual, and whether they want to be a cog in the wheel, or whether they are interested in both improving themselves and thereby improving their employer.
Yes this is important, but I think if your employer is in mood to listen. The next immediate step for you must be to start fishing for a job outside. And there is a reason for that. Your time is worth doing something important which is rewarding to you and your employer(I mean both in terms of value and financially).
Challenge the status quo and try to improve things, if you absolutely cannot(for reasons beyond your control) you must leave people to their state and move on.
At some point in the growth of a human being, we are discouraged from continually asking "Why?" and from questioning things we see. This is largely a bad idea, so showing junior devs that they are in a position to ask questions and help lead everyone to a better solution is great!
Based on my experience, it would be unrealistic for a junior developer to expect this perspective at a new job. More realistic: here are the things that need to be done for this business to survive; please do them. Maybe some leeway in how you approach the problem. If they wanted unbiased eyes, the job listing would have said consultant, not junior developer.
Believe me, I hear what you're saying. I've tried it many times. For instance: "You don't check everything into source control? Oh my god, it's so basic, look how much better you guys could be doing your jobs!" Which, yeah, it would have been better. It also annoyed the people around me and destabilized the team, even as it improved the technology. Net loss for the company.
Having made this mistake over and over, I want to help others avoid it. Junior developers, know that if you find success in your job, your most important contributions to the company will not have been code. You will not bring some great insight to the table that makes everything faster/better/cheaper and wins you everyone's respect. You earn respect and admiration by working hard (not smart, hard!) and helping the people around you. Look up from your text editor, go talk to people, find out what they're doing, help them succeed.
That's where your focus should be as a junior. (Or as a senior, for that matter.) Helping others succeed. Questioning the status quo is a distraction and not as useful as you think, even if you're right and everyone else is wrong. Maybe especially if you're right.