ООП в картинках

Вы описали не инкапсуляцию, а сокрытие.

Интерфейсы — это такой костыль для языков, разработчики которых не хотели реализовывать множественное наследование, а точнее бороться с «ромбами» реализаций. Классическая иллюстрация — Java, где после появления default реализаций, интерфейсы это по сути классы без non-static field'ов. То есть абстракция получилась очень дырявая.

С другой стороны, проблема "ромба" именно при наличии полей в базовом классе и проявляется наиболее сильно!

Интерфейсы — это такой костыль для языков

Паттерны проектирования, в общем случае — зло.

Почему бы для рисования сразу не использовать UML?

и правильно применять паттерны, особенно в рефакторинге легаси-кода.

Делаете рефакторинг, делаете так как лучше, не оглядываясь на паттерны. Увидели сходство своих изменений с каким-то паттерном, добавили соответствующий суффикс к названию класса. Оценили отличия классической и вашей версии, изменили код либо добавили пояснения в документацию, почему отличия присутствуют. При этом паттерны это довольно абстрактная вещь, если отличий слишком много, возможно это другой паттерн, или вы делаете что-то неправильно.

Я привык к стилю программированию на чистом Си (в основном всякой математики), без ++, и соответственно возникает вопрос — а зачем мне использовать ООП, если можно и без него.

Любые описанные механизмы, принципы и паттерны, как и ООП в целом не стоит применять там, где это бессмысленно или может навредить.

class Starship
  {
  private $position;

  public function fly(Vector $coords) {}
  public function moveTo($coords) {}
  public function hyperjumpTo($coords) {}
  public function shootAt($coords) {}
  }

$myStarship=new Starship;
$myStarship->flyTo($someRandomPoint);

abstract class Starhip {} 

class StarDestroyer extends Starship {}

class SuperStarDestroyer extends Starship {}

//Название не совсем удачное, поскольку Imerial/Rebel на самом деле не указывает на владельца
abstract class ImperialStarship extends Starship {}
abstract class RebelStarship extends Starship {}

class StarDestroyer extends ImperialStarship {}
class SuperStarDestroyer extends ImperialStarship {}

class CorelianCorvette extends RebelStarShip {}
class MonCalamariCruiser extends RebelStarShip {}

//ну или Shipyard
class ImperialWarf () : ImperialStarship {}
class RebelWarf() : RebelStarship {}
class CorelianWarf() : Starship {}

abstract class Starhip 
  {
  public function shootAt(Starship $target)
  }

interface Destroyable {}

abstract class Starship implements Destroyable {}
abstract class Planet implements Destroyable {}

//ее по канону конечно нужно сделать синглтоном, но кто знает....
class DeathStar extends Starship
  {
  public function destroy(Destroyable $target)
  }  

class GalaxyFarFarAway
  {
  private static $planets;

  public static function getPlanetByName(String $planetName) {}
  public static function getRandomHabitablePlanet() {}
  }

$myNewShip = new MilleniumFalcon();
$destination=GalaxyFarFarAway::getPlanetByName('Alderaan')

$myNewShip->hyperjumpTo($destination->getCoords());

$myPrecious = new DeathStar();
$victim=GalaxyFarFarAway::getRandomHabitablePlanet()

$myPrecious->destroy($victim);

какие задачи стоит решать именно через ООП?

Те, решение которых без ООП оказывается менее поддерживаемым. Если вы пишете математику и на C, скорее всего, вам это низачем не нужно.

Не хватает раздела: «а зачем?». Ну серьезно, очень многие так увлекаются, что KISS, YAGNI итд для них не существует, есть только сферический ООП в вакууме.

Ну вот холивара ради(ну все равно почти под каждой статьей про ооп такой есть): допустим ваши трансфомеры начали сражаться друг с другом, соответственно нам понадобиться расчитать опыт/здоровье/щиты/прочие штуки, а потом обработать собственно убийство. Тут сразу возникнет вопрос: а где и как? И на этом этапе многие скажут, что нужен класс CombatManager, которому нужно передать трансормеров, вместо optimus->attack(megatron).

По поводу 4-го уровня. Не понятно, тут разве не о крафте в играх говорится?)

Если есть такая метка, то можно добавить в список возможных значений новое, то есть — добавить новый класс.

А поведение, связанное с этим новым классом, вы как добавлять собираетесь?

А то если его нет, то у вас и нового класса нет, на самом деле...