If it's complex and hard to maintain, then it's not dumb code. It's genius code. Dumb code is actually very hard to write successfully in production and there isn't a recipe for it. The novice flails and makes the code too complicated trying to add one hack on top of another without doing any causal analysis, the journeyman programmer starts throwing in a lot of defensive abstraction they learned about yesterday that doesn't tame the problem at hand, and the expert writes a correct solution that is exactly what is needed and no more. As a bonus, when you enter a new problem domain you're a novice again. All that stuff you knew about working with databases is irrelevant if you're working with real-time audio. But you get to skip through the cycle faster this time.

Ergo, dumb code. It's hard to make dumb code that actually stays dumb instead of turning into genius-level complexity or bad abstraction.

That is some interesting definition of genius you put in here. Usually the criticism of so called genius code is about manual optimization and sometimes domain specific optimization and not about crust achieved over years of lacklustre maintenance.

There ate actual real reasons you shouldn't or cannot write dumb code. One piece of such "cruft" is handling numerical corner cases which is unavoidable unless proven mathematically to be impossible (And commented why). Using IEEE floating point? Guess you get to handle ULP precision, NaN and Inf. Using integers? Welcome to wraparound. Memory management? What happens if an allocation fails? Threads? Race freedom is quite interesting to achieve.

Using Java? Then figure out what happens when you choke GC with hundreds of objects. Etc.

You can only go so far in passing the buck to library authors, they can make mistakes too.

Curious, what are your top 2 favorite languages (or CS thinkers)?

Simple also gets us into trouble.

Straightforward is the way to go.