Quote:
Classic example: Object needs to destroy itself, because somebody just shot it in the head with a freakin' laser.

Classic mistake. Object needs destroyed as a result of some game rule. Game rules know full well about the components of their world.

Mis-assigning responsibility is a programmer error regardless of paradigm.

Object-Oriented programming provides you with tools that help you achieve several things:

• Open-Closed interfaces: you can alter the behavior of a certain piece of code without changing it, simply by providing a polymorphic object argument that does what you want. Other means of achieving this are functional programming (you would pass a function) and aspect-oriented programming (you would bind a behavior to an internal event).
  
  
• Encapsulation: you can group together related pieces of functionality that operate on a certain piece of data, and hide the whole behind an interface to achieve polymorphism. Other paradigms have more difficulty achieving this, which leads them to designs where this is not required.
  
  
• Dynamic designs: instead of having a design defined at compile-time, an object-oriented program can alter its design at runtime by adding or removing components and configuring object dependencies on the fly. This allows more freedom, but also makes program architecture more confusing to understand.

In addition to this, typical Object-Oriented programming also incorporates some more general concepts found in other approaches, such as separation of concerns (the Single Responsibility Principle and Interface Segregation Principle) which makes code more modular and therefore easier to extend, and the Dependency Inversion Principle, all of which can be commonly found in good procedural and functional code.

As smcameron points out, Object-Oriented programming also has its flaws. Optimization, for instance, relies on knowledge that helps improve performance, which can sometimes come at odds with the tendency of objects to hide their internal details (and therefore, useful knowledge) from the rest of the code. The example chosen here is silly: if performing a boolean check for every object were a significant amount of performance, then effort should be spent to avoid updating all objects every frame, for instance by using a priority queue based on the time of the next update. But there are more serious examples out there, such as the performance difference between performing SQL queries by hand and using objects and an ORM.

Be wary of premature optimization—there is never any point to optimize code that might be removed tomorrow. Only once you're fairly certain that a piece of code will not be changed anymore can you let tightly encapsulated objects leak information. To reuse smcameron's example, assume that instead of setting an isdead boolean, the object instead removes itself from a list of objects then deletes itself. This approach prevents us from storing the object in other lists (such as 'enemies that are about to appear in the game') or even be referenced by other objects (such as 'the target of a homing missile'): you have to find a way to notify all referencing objects that you're dead, which is harder to achieve if you just blast yourself out of a list as soon as possible.

As a final remark, don't plan your design. You don't have the experience required to think up a flexible design on your first try, because by definition you can't think of everything. The simplest way to create your first object-oriented design is to discover it: write your code as you normally would, and once you get stuck (because the design was bad), think of how you could have designed everything so that you wouldn't have gotten stuck. Keep things simple: don't just add complexity to your design, also think of ways to make it simpler. Once you have a good alternative design, refactor your code. Use unit tests to determine that you haven't broken anything.

After a while, you'll get used in advance to the various pitfalls of your designs, and you will be able to plan accordingly.