Почему мне кажется, что студентов учат ООП неправильно

Но отсутствие контрактов не означает отсутствия классов или отсутствия ООП.

Ограничения доступа — прежде всего в голове у программиста.

class A {
    name = "world";

    hello() {
        return $"Hello, {this.name}!";
    }
}
class B extends A {
    constructor() {
      	super(); // В конструктор? Хотя вызов работает и без него.
    }
  
    name = "B";

    who() {
        return $"I am {this.name}";
    }
}

var b = new B();
console.log(b.hello()); // Ну и куда тут надо было super засунуть? :-)

Строгого определения ООП автор Smalltalk не давал (впрочем, то, что он пишет в конце своего письма, вполне можно считать определением). Как, впрочем, такого определения и не давали авторы языка Simula. Оба языка при этом примерно одновременно ввели термин "объект". Соответственно, можно говорить о двух "школах" — "Смоллтолковской" и "Симуловской".

Появившийся позднее язык С++ был явным последователем Simula-школы, и именно в те времена — благодаря тому, что С++ был долгое время самым популярным объектно-ориентированным языком — в массовом сознании закрепился сформулированной Страуструпом триплет "инкапсуляция-последование-полиморфизм" и стал считаться чем-то вроде определения. Примерно в то же время появился и другой основанный на C язык, известный в то время в основном только немногочисленным обладателям компьютеров NeXT, следовавший принципам Smalltalk… :-)

Что касается определения.

Во-первых, предлагаю смотреть не в википедию курильщика, а в википедию здорового человека — то есть, в английскую. Никакого упоминания необходимости и достаточности свойств из того самого "триплета Страуструпа" вы там не найдете: они, несомненно, перечислены, но только в общем ряду других свойств некоторых объектно-ориентированных языков.

Во-вторых, сравним высказывание Алана Кея и Страуструповский триплет. Вот что пишет Алан Кей:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

Вызов метода можно считать частным случаем Messaging. "local retention and protection and hiding of state-process" — по сути, инкапсуляция. "extreme late-binding of all things" — по сути, полиморфизм.

Итого, общими являются инкапсуляция и полиморфизм. Наследования у Кея нет.

Более поздний принцип проектирования объектно-ориентированных программ, высказанный применительно к языкам Симула-школы, гласит: предпочитайте композицию наследованию. С этим принципом согласно подавляющее большинство специалистов по проектированию ПО: Мартин Фаулер, Джошуа Блох, Эрик Эванс… Все они рекомендуют по возможности избегать наследования в тех языках, которые наследование реализуют.

Логичный вывод: наследование не является обязательным признаком ООП-языка.

Это не важно, все равно сущности плодятся.

Что значит "плодятся"? Оба понятия, и "книга" и "товар", есть в предметной области магазина. И это разные понятия.

Это неудобно. У вас получаются двунаправленные связи.
С одной стороны, когда печатается чек, мы из SKU лезем в книгу за названием.
С другой стороны, когда ищем самый дешевый букварь — у нас сортировка книг по цене

Когда печатается чек, у нас основаня сущность это SKU. Когда ищем самый дешевый товар определенного типа, у нас основная сущность тоже SKU.
Это сводится к запросу вида WHERE product_type_id = 123 ORDER BY price LIMIT 1, и это не куча джойнов, а 1-2, в зависимости от реализации, которые к тому же неплохо заменяются на отдельные запросы с IN.

Связи между сущностями есть, только они идут из предметной области и вы никуда от них не денетесь. А если попробуете, то да, у вас будут все эти "проблемы с ООП". Только это не из-за ООП, а из-за неправильной архитектуры.