Let's consider the flipside. I've just joined a new team, and their typical onboarding time is 3 months because their codebase is an unnavigable mess. They have a few hundred thousand errors per week in prod and generally just ignore their logs because it's impossible to find anything meaningful, so you don't really take any action unless their dedicated support team pings you (yep, it's so bad it needs a dedicated support team, one of the only ones in the entire org). They're somehow considered high-performing, but that really boils down to being good at estimates and commitments, not having maintainable code

It seems the only viable way to make changes here is to introduce them incrementally - you can't just outright tell them their code is the worst thing you've ever seen. This means during planning discussions, often focusing on one or two important and fundamental changes, and discussing why the old way is broken - naming is probably a good candidate to start with. The team's not a huge fan - their usual approach is to just do it the way it's always been done, which is why they're in this mess, so they're not used to drawn out discussions.

Then, whenever making changes for a story, you can start fixing related components that you would never get approval for, or at worst, demonstrate better new design principles in the new feature. You should, of course, provide the reasoning behind why you made the change, in verbose detail. They'll probably argue that it's not the way it's always done, and ask you to just do it the "normal" way, but unless they can provide substantiated arguments about why their way is better, you should push back a bit until they actually discuss and consider, instead of just the usual knee-jerk reaction.

Everything that goes into a codebase is effectively permanent, and can almost never be refactored - in this culture, it will be copied around everywhere over the next 10 years and become the new standard, and you've got to maintain it, so every small decision is important, and affects you personally

And sure, maybe that attitude is detrimental to the team culture - which is a good thing, when the team culture is just "do it the way it's always been done"

After a year or two of making the team actually think more deeply about their code, now I no longer am the one debating small things for most of the meeting - they've started to consider how things are done on a fundamental level, and are willing and able to change them on their own, and are actually great engineers once they put some thought into it. The codebase is slowly turning into something worth having as changes are iteratively applied to them, and new projects are a breath of fresh air because there's finally some thought put into how they should be structured. These new approaches aren't always the best strategy, and sometimes we collectively decide that yep, the old approach was better, but trying and failing is better than stagnating and assuming

(This is a real story of my last job, but it seems to parallel yours quite naturally - so consider it from their POV)