It's awful in games too, although the grain of OO languages makes it a little more compelling at first. OO encourages slicing up code into black boxes, and it just doesn't work.
What a game needs is a database view of the world - not a strict formalized model like SQL, but a customized, mixed-paradigm mode of keeping a ton of global state organized. Game actors are not truly independent, they're a view on various fragments of data allocated semi-independently and late bound into some association. They're all part of one world.
You're exactly right. The problem with OO is that you are really making state changes in what you should think of as an in-memory database, but the languages offer you no support for doing so logically. A logical language, or as you suggest, a mixed-paradigm language, could give you some logical assistance in enforcing consistent state transitions. In OO languages, you have to enforce all the logical constraints yourself, in code. And you get so used to it, you begin to think that's the way it's done, and you embed the knowledge in your Patterns book.
What a game needs is a database view of the world - not a strict formalized model like SQL, but a customized, mixed-paradigm mode of keeping a ton of global state organized. Game actors are not truly independent, they're a view on various fragments of data allocated semi-independently and late bound into some association. They're all part of one world.