Saboteur

ООП это просто парадигма программирования, которая объединяет данные вместе с методами, которые работают с этими данными напрямую, в классы.
Классы взаимодействуют друг с другом через методы, а не через прямой доступ к переменным. Так достигается инкапсуляция.

Все, теперь ты знаешь что такое ООП.

А учить нужно стандартные библиотеки, классы и популярные паттерны, и это уже на практике, и всю жизнь.

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

А может быть их и не нужно понимать, т.к. их редко используют?

Именно так.
Если часто будешь использовать, научишься понимать.
Если редко - будешь разбираться, а потом забывать.

Но UML это всего лишь один из вариантов, как фиксировать контракты. Может быть и достаточно удобный и стандартизированный, но не все им пользуются, ибо нарисовать UML это тоже время и задача.

Не заморачивайся на чем написан питон и с ООП или не ООП написан он сам.
Но если ты читал хотя бы введение в питон, ты бы узнал, что в Питоне все является объектами, а следовательно все типы данных это классы.

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

Раз все программы оперируют некоторыми данными, то нужно взять эти данные, взять функции (методы), которые работают с этими данными и поместить в один объект.
Если нужно будет изменить тип данных, добавить/отнять/поделить функционал, то программист будет работать с одним этим объектом. При этом, если разные объекты запрашивают что-либо друг у друга, то в ООП довольно легко сделать версионность и обратную совместимость.

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

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

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

Формальная логика там присутствует потольку поскольку. И никакой дополнительной логики в этом искать не нужно - это будет не практично. Реализация ООП подгоняется и меняется в соответствии с практическими требованиями, а не математикой. Собственно отсюда и идут постоянные споры.

Если у вас проблема с тем, как делить код на объекты, это означает, что
1. Вы плохо продумали архитектуру проекта, либо вообще плохо представляете что должен делать проект.

2. Мало опыта - в таком случае не парьтесь, просто пишите код как можете. опыт придет с набиванием шишек, когда будете рефакторить код и понимать что наверное надо было вот так изначально разбить, чтобы сейчас было проще.

3. ООП был придуман как выход для написания крупных приложений, которые пишутся большим количеством программистов. В отличие от модульного программирования ООП позволяло не только разбить код на отдельные куски, но еще и сделать эти куски инкапсулированными независимыми "объектами", каждый из которых может поместиться в голову среднестатистического программиста, чтобы упростить процесс разработки.
Это одна из причин, почему ООП достаточно сложно освоить на маленьких проектах.

Например, потому что могут быть методы, которые вызываются только внутри этого класса. И очень полезно, чтобы снаружи они были недоступны.

Если создаешь Public методы - это означает что кто-то может его использовать. И в случае крупного продукта - это может быть другой программист, а может даже другая программа. И если в будущем захочешь модернизировать, то со всеми public методами нужно думать про версионирование и legacy саппорт.

Не знаю, насколько вы разбираетесь в общем Computer Essential, но вы знаете, что на русском языке можно писать детективы и фантастику, можно писать исторические экскурсы с реальными данными и документалистикой, можно писать журналистские новости, можно писать анекдоты и шутки - и все это всего лишь на русском языке.

Тоже самое и с любым языком программирования - смотря куда устроитесь, те технологии предпочтительнее изучать. С++ используется широко и для embedded и для системного программирования и для десктоп приложений и для game development и для различных плагинов/расширений. И везде могут быть свои технологии.

Пилите свои любые проекты, чтобы получить опыт завершенного продукта.
sql нужен вообще везде.