Legacy code is part of software development life cycle. We work in the fast-changing environment. This beautiful class you're writing today could be considered ugly and obsolete in just a few years. So my first advice would be: don't make judgments if you don't know for sure why exactly it was decided back then to go this particular way. Maybe, not all of the options were known, and "the worse one" has been chosen not intentionally. And now, as you mentioned, everybody knows better practices, but they prefer to stick to that style for consistency reasons. And being pragmatic, it makes sense to keep everything in the same manner, doesn't it?
With that said, I would recommend being vocal about your improvements ideas. Perhaps, nobody will ever allow to re-write the whole thing. But coding standards are the subject for continuous improvements, and a healthy team understands that. How about making a presentation on why vectors are better than arrays? Or starting a discussion in a team chat/email about the appropriateness of custom implementations for standard objects? Of course, it would be nice to share a couple of links, let's say, to blog posts from big names in the industry, to strengthen your position. And when you'll have any kind of consensus after these discussions, be proactive and create a poll about acceptance of this idea as a standard from now on. Even if it won't be accepted, you'll learn something that is unknown to you at the moment.
But if it will be, you'll see how much you can do even if the codebase is old and big and it is seemingly impossible to fix all. Start with baby steps: have this rule working only for a new code, even if to implement a new feature you need to touch old parts of the system where many methods are still "ugly". Next, apply the boy scout rule: if you see "the old style" somewhere on the way, and it takes not more than an hour to fix it, - rewrite. Then, if applicable, an automated check could help to detect all of the places that need attention and estimate the real effort to absolutely get rid of this (it could be surprisingly small, by the way). And if you add this check to a pipeline, you'll force everybody to fix that stuff even if their task was not related to that particular method with an "old style". With all this one day it will disappear, I promise.
And one more situation to show that changes are more possible than you might think. In the business world, we need to speak in business terms. Refactoring for the sake of refactoring itself adds zero value, but when you are able to demonstrate how this change will impact results, you'd likely to get the green light for any request. Sometimes, the maintenance of one particular part of the code is painful, while the reasonable rework effort will speed it up dramatically. I encourage you to speak up instead of struggling with it. Bring up some numbers, make rough estimations on how long the feature enhancement will take with and without refactoring. Sell this work to your tech lead/product manager/another relevant influencer as necessary, and the choice would seem obvious for them. After this success, "suddenly", you'll find yourself leading a project of making this part of codebase a place where modern coding standards come to play. Go for it! Just be sure to have tests for all the critical functions before you even start! ;)
Good luck, Michael.