We like to talk about how code is written, because we look at code all day. The rest of the world only cares about what your code does once it's compiled.
Senior engineers solve problems. They're not overly concerned with ticking all the boxes just so they can get a "good code" sticker.
While I do agree that many developers sometimes like to argue about "code quality" too much (and I've probably been guilty of that at times), "code quality" is definitely a real thing. I have have interacted with code bases that were a joy to read/modify, and I've interacted with code bases that made you pull your hair out at every turn (and also many levels in-between the extremes). It is not always a case of just "arguing for the sake of arguing".
But I strongly disagree with the sentiment that someone should not write code in a certain language, or should not contribute to a project until they know how to write idiomatically according to all the "accepted" best practices. It's a pedantic and elitist attitude which has little to do with making good software, and runs counter to the practice of learning how to use a language, which is necessarily a process involving ignorance, trial and error.
As a senior I can pretty quickly tell in the languages I write in often, when something is a smell, and if you keep repeating some code smells for a like a year you'll start seeing compounding effects on development speed. Understanding when to allow those with good reason and when to coach someone to stop doing those is an important skill for a senior imo.
But it's definitely not immediate, way more of a pernicious concern, the codebase will effectively rot until it's painful to make changes.
The point where this happens depends a lot on problem domain. If you're doing well-understood CRUD-screen database stuff but applying it to a novel business domain, you're probably not going to hit code quality issues. If you're doing heavy algorithmic, OS, financial, or networking stuff, though, where failures compound and any one bug might take the whole system down, you really want to pay up for experienced developers that have seen all the ways these systems can fail.
That said, I can really only speak to web api dev, data engineering and search. I'd say out of all of those search was the tightest area with regards to quality and even then I was lucky to be working with another very talented dev. Him and I didn't run into very many issues we were unable to solve with scaling the technology even after hitting 100m pages or so and we could have kept going on scale but we were cost constrained, navigating the business side was far more challenging for us.
I'll admit as well I've been pretty lucky so far to work in situations where code quality is considered and managed and haven't yet worked somewhere where the concerns were entirely ignored or the team didn't care.
People in your company (including non-engineers) definitely care, because code quality bears on how easy it is to debug problems and how easy it is to implement new features or fixes (or sometimes if a feature is even practicable).