Could he hire on another person to work on the non-simulation bits? Perhaps. But that takes money. Tarn makes donation information public, and he makes between $40k-50k a year before taxes and the ~$800 a month he pays his brother for the help he provides. Enough to support himself, but not nearly enough to hire on another full time person.

Not to mention there are already other games out there attempting to emulate Dwarf Fortress (Gnomoria and Towns immediately come to mind) in a more user friendly form, but neither of them yet come close to intricacy and scale of Dwarf Fortress.

Regardless of that, well engineered code is far easier, more flexible and waaaay faster to maintain in the long run when compared to a mess of quick dirty hacks to get passable results. It takes no time at all for the hacks to impede your ability to make changes to the system.

Early in a project it's often difficult to get the design perfect. Requirements are refined and unforeseen engineering challenges crop up. When this happens your existing design pattern may no longer be a perfect fit. This is how I approach it:

I think about what the new 'ideal' or obvious solution is considering the new challenge.

If that solution is not practical to implement. I may try to engineer around the problem in a way that is consistent with the design of the rest of the system. While it may not be the 'optimal' solution the next developer who needs to get in there and change something will readily understand what's going on if they are familiar with other parts of the system. I like to call this 'fractal' design.

I rarely encounter a situation that I cannot solve via the ideal or fractal approach. But only after I have ruled out both do I allow myself to resort to hacks.