I find this post suggestive. The title—"from the trenches"—makes the important point that this is a reflection from experience on what seems to work best where.

I find this post suggestive. The title—"from the trenches"—makes the important point that this is a reflection from experience on what seems to work best where. That's more valuable and harder to come up with than it sounds, because if you identify with a paradigm then you don't easily notice it getting in your way. I would like to hear a more detailed treatment of the distinction between "dealing with data about people" and "simulating people". If these overlap (and surely they do), then you get into a circularity where your favorite paradigm leads you to see a problem its way, just as much or more than the problem nudges you toward a paradigm for solving it. On the other hand, my experience matches the OP's that OO's sweet spot is close to its origins in simulation--where you have a working system that exists outside your program, your job is to model it, and--critically--you can answer questions about how it works empirically. When you aren't simulating anything, OO is cumbersome because it requires you to name and reify concepts that become "things" in your mind; these ersatz "things" continually draw attention to themselves and get between you and the problem.