Понимание ООП приходит с опытом. Сначала надо написать много кода, самому заметить его недостатки и тогда перечитывая те же самые статейки вы начнёте по новому понимать, что вот конкретно эту штуку можно было бы использовать в том моём коде, и было бы лучше.
Я разделяю ООП на аутентичное и классическое. Аутентичное, это ООП как его представлял автор - объекты обмениваются сообщениями.
Классическое - это то как оно реализовано в Java.
И там и там есть инкапсуляция и полиморфизм. Наследование это приятная фишка классического ООП. Так же как и все пляски с типами. Вообще строгая типизация не является частью ООП. По крайней мере не является частью аутентичного ООП.
Поэтому переход на typescript позволит только более точно воспроизводить классическое ООП. Ну и проверку типов добавит. Это само по себе полезно, но для ООП никакого значения не имеет.
В общем,. Надо всегда помнить о двух вещах - инкапсуляция и полиморфизм. Необходимо выделять некоторую самостоятельную функциональность в отдельные объекты и писать код так, чтобы решение о том какой код выполнить делалось не кучей условий, а на основании того, какой объект сейчас лежит в переменной.
Заметьте, про js я почти ничего не сказал. Потому что дело не в нём. Дело только в понимании ООП. У языков программирования, конечно, есть различные возможности и ограничения что которые позволяют использовать ту или иную парадигму. Но ООП на js можно было делать и до es6, просто потому что в js можно инкапсулировать код в объект.
И ещё, когда мы начинаем делить код на объекты, необходим механизм разделения кода на файлы и собирания его обратно. Т.е. нужна модульность. Лучше всего, конечно, использовать webpack, но вроде как в js есть и другие системы. Не сборки, а именно подключения модулей.