Let me offer you some advice, based on a few years in the games industry: I think every other industry's approach to code cleanliness breaks down for complex, intertwined simulations with strict performance requirements.

If Google cared at all about the targets that game developers cared about, my Gmail wouldn't take 10 seconds to load and run at 2FPS once the page is there.

I've read some of the best code I've ever seen, written by programmers in the games space. Code with very few tests, heavy intertwined behavior, wide-reaching global effects, and lots and lots of state.

Ultimately, treat the code as an artifact of the project: make it as clean as you need to get the game done, but any extra scaffolding you add will only come back to bite you later once you want to change how something is wired. From that end, all the usual suspects apply: make code easy to delete, make it have clearly-defined boundaries, and depend on other code as little as possible. Push yourself to use copy/paste more than you think you should, you'll be surprised how easy it is to delete wild experiments if you don't have to untangle the web of dependencies.

I worked at EA for eight years and have worked at Google for the past ten. Google and the GMail team most certainly understand how to write performance critical code. Your favorite game would take 10 seconds to load and run at 2FPS too if it had to be pushed over the Internet every time it started up and run inside any of a few only mostly-compatible VMs for a dynamically-typed scripting language never designed for anything more important than making buttons light up when you hover over them.

You're correct that optimized code is generally harder to maintain. Optimization often requires punching through abstraction layers or calcifying certain constraints or assumptions in the code.

If the GMail team understands how to write performance critical code, then there must be something else to explain why they no longer do. Hmmm... by making old hardware unusable, they cause hardware upgrades, and somehow that drives licensing? The simpler explanation, fitting Occam's razor, is that the GMail team does not understand how to write performance critical code.

FYI, about a dozen years ago I comfortably used GMail on a 450 MHz PowerPC with 512 MiB of RAM. The javascript ran without a JIT, completely interpreted. It all ran just fine. Now here I am, on a multi-GHz multi-core box with gigabytes of RAM and a JIT, and I have to keep GMail in HTML-only mode. I simply can't run the javascript and still operate my computer. Mail is piling up because I can no longer select lots of email for deletion; it isn't practical to click every single item.

I'm a game dev, and I work on high-performance websites in my spare time (e.g. https://noclip.website/#mkwii/beginner_course ). It's actually possible to make stuff that runs fast in "mostly-compatible VMs for a dynamically-typed scripting language never designed for anything more important than making buttons light up when you hover over them" if you actually try. But Google does not, so we end up with gmail.

Thank you for the advice. :)

over DRY code is the bane of my existence

Look into Jonathan Blow's work. He doesn't churn out garbage code. He cares about his craft and that includes artisanship in the games he builds.

With all due respect to Jon Blow (and I respect him a whole lot!)-- I don't think he'd be able to do what he does if he didn't make a boatload of money off of Braid.

Braid itself was novel because it took game state and made it immutable, immutability often needs a lot of consideration

This is definitely speculation on my part but maybe he didn't become a coder focused on his craft because of the finances afforded to him from Braid, maybe he created Braid a quality game because he was a coder focused on his craft?

But he made a boatload off of Braid after he coded it. Not sure I understand this point.

To me Braid was literally the first example of him doing what he does.

You say he doesn't write garbage code, yet none of his source code has been released so you've never seen it. How do you know if it's good code or not?