I've never worked in a fantastical position like this. The only purpose of the source code that I've been a part of was to provide a real solution to a real problem, in a limited amount of time, with too few resources. Technical debt always increased slowly until features are removed or break, forcing some dedicated work.
Can I ask what industry you're involved in where code quality is held higher than profit/deadlines/solutions? I would happily make the jump.
I've actually been doing a lot of turnaround consulting with companies that took a short term mindset, got stuck, and had to step back and revamp their technical processes like you say. It's always more expensive to redo it after the fact, but I'm happy to take their money and fix their mistakes.
And that's not to say that it's not a tradeoff, but it's about being conscious of the tradeoffs involved and making reasonable choices.
The primary purpose of source code is to be understandable and manipulable by other engineers. No matter how well it accomplishes its goals, it's not "good code" unless it can be understood by other people.
I question whether you're actually working with a "very complex product" - it might just be that the way you're representing it is complex. If the code is still too complex to other engineers after 6 months, it's not the engineers who are wrong. At 6 months they should deeply understand some parts of the code and have confidence about diving into and understanding other parts with some ramp-up time.
I say this as someone who writes a lot of code that other people find hard to understand because it's "clever", and it's taken me a long time to fully internalize that, when someone else can't pick it up, it's not their problem, it's mine. Code is user interface, and good user interface meets the users where they are, not where you wish they would be.
Honestly, this aspect of software engineering is really the bottom line hardest part - it's not getting a working binary out of the compiler/interpreter, it's about getting a living system to evolve well. That means nomenclature and abstractions have to be top notch, not just the algorithms.
There's an old saw about "if it's twice as hard to debug code as to write it, never write code that's more than half as clever as you're capable of, otherwise you'll by-definition be unqualified to debug it", and I think there's a lot of truth there. One of my old director of operations used to say "If you can't run the playbook at 3am after being at the bar, it still needs work", and I think that's also true of non-ops related code.
Your next step is to reorient your role: your job is no longer to ship features, your job is to make the code easier for your coworkers to execute in. You're right that you'll "stop coding" as seen by management: your new bosses are your coworkers. Treat them as your customers, have them file tickets, the whole nine yards. When you reach the point that your coworkers are faster at getting things done than you are at the moment, then you can turn your sights back to production work, but until then, your job is technical debt remediation.