Okay here's my actual decade+ software engineering experience take on the Balatro if. Huge caveat that game development and software development are actually wildly different skill sets and I'm not very good at the former, so take this more as "inspired by" than "about" Balatro's code specifically.
Knowing when to do things stupid is a critical skill.
A lot of software engineering education, as well as on-the-job discussion of what sorts of practices can improve engineering outcomes, focuses on abstraction and automation. And indeed, finding the right place to to create an abstraction that makes it easier to think about the problem space, or a tool that will save you way more time than it takes to write, can be hugely valuable. I once spent a big chunk of time pulling everything about Sass's deploy process into a nice clean re-usable package and now all our improvements are shared among our several CLI tools as well as tools made by other people we don't even know. Fantastic!
But there's negative space that's also very important. Sometimes—a lot of the time—it's better to just do it the hard way. If you try to do everything the most generic way from the word go, you'll never have time to actually get anything done. Worse than that, you're way more likely to end up abstracting the wrong thing! Getting your fingers into the manual code is critical for understanding what parts actually need to be abstracted and what parts are either so context-dependent they need a human's touch every time, or just easy enough on their own that the abstraction doesn't add any real value. (The latter is where Balatro's if statement presumably falls.)
i think defaulting to doing it "the dumb way" and then developing your sense for where the "okay, this is silly, i'm making a tool to help me with this" line sits is a very reasonable way to do most software development

eggbug enjoyer