I see more problems than just a refactoring here.
I've also asked management if we could have some more deliberate planning or cleanup for the codebase but I was basically told no.
Did you talk to your direct team lead? Management is a very broad term, and can include anything from team lead of your 20+ people up to a a CEO of the entire company as well as other company pillars' management (aka Operations or Business management; note that any level CEO is usually more of Ops/Bus as well).
Essentially the person you have to persuade is your direct (line) manager. The one responsible for the team. If you manage to convince them, you're on the right way. It'll be then their decision if they want to apply changes without notifying anyone or seek further approvals. They are also responsible for building the culture of coding.
I've had some 1:1 conversations with team members and most of them are also aware of the various code smells and don't like them
This means you actually have a very strong basis. In most companies there are team meetings and there you can bring up the point of improving your coding practices in general. Talk upfront to 2-3 colleagues that you think might be most interested in it as well so that they can back you up at the meeting. That will strengthen your discussion position.
Prepare your arguments. Look for the analysis of impact to the code, programming efficiency etc when it is not written properly. The term "technical debt" has been already mentioned in other answers. This is what you need to look for in general.
Think also about actual problems that you or your colleagues/a whole team experienced due to those problems. Will you be able to spend less time if the code was uniform? Will there be less errors during code integrations?
Everyone on the team programs in their own way and there isn't any coordination.
This, rather than the refactoring itself is the main and first thing to address. What's the point of refactoring if you will be back to the same (lack of) code quality in another 2-3 years (at best). In reality your refactoring will be slower than introducing the new code, so it will be simply a waste of efforts. Focus on discussing how to improve new code quality in the first row, agree on the practices to follow, add code reviews as a mandatory part of your coding to ensure the practices are followed.
In other words - stop doing more mess (aka acquiring more technical debt). Of course, you'll always have challenges with that and sometimes you might end up with some deviations from the standard but each deviation should be immediately fixed before moving on to the next project.
but refactoring rarely happens because there is always something more important to do.
Once the previous point is achieved you can move on to the refactoring, In reality make it a part of your coding practices immediately but only once the standards are settled.
Refactoring is not about making a huge single change (again - as already pointed out in other answers). It's about continuous improvement of parts of the code neighbouring what you currently write. Make it a custom that you're fixing a line of code or function that you're about to use. Just one at a time. Make sure to have unit test (if you don't writing them one is also a part of your refactoring).
With this approach it'll be easier to blend the refactoring into everyday work. You need to account that when assessing the workload for the actual coding. Only if you give yourself the required time, you'll be able to do that. And no-one will most probably object, since they have no idea what you are really doing. Of course as long as you have your managers consent.