Сергей

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

если консоль понимает ANSI коды, то

import random
import string
GREEN = '\033[92m'
RED = '\033[91m'
ENDC = '\033[0m'
x=list(string.ascii_uppercase+string.digits)
for i in range(10):
    random.shuffle(x)
    y = [GREEN+l if  random.random() > 0.1 else RED+l for l in x]
    print(*y)

print(ENDC)

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

Вообще, это правильный подход к диаграммам. )
Вот что писал Боб Мартин:
"Возьмите за правило выбрасывать ненужные UML-диаграммы. А еще
лучше, не создавайте их на постоянном носителе. Рисуйте на доске или
на клочках бумаги. Почаще стирайте с доски и выбрасывайте эти об-
рывки. Не привыкайте к инструментарию CASE или к графическим ре-
дакторам. Для таких инструментов есть свое время и место, но жизнь
большинства UML-диаграмм недолговечна."
Хотя, далее, некоторые полезно и сохранять. Общий дизайн системы (идея) или те моменты которые из текста программы будет сложно понять.

Упрощенно можно так подходить к выделению классов и интерфейсов.
Есть два реальных объекта. Они относятся к разным классам. Со своими особенностями. Но у них есть некие одинаковые свойства. Например шаблоны функций. пример в общем случае быстрая сортировка это шаблон реализующий алгоритм, но этот шаблон не знает как реально сравнивать объекты. То есть это абстрактный класс объединяющий конкретные быстрые сортировки конкретных объектов. Можно сказать, что абстрактный класс это вынос общих методов и полей их своих потомков. При том что реально мы никогда не создадим экземпляр этого класса.
Выделение интерфейса. Обычно применяется для разделения систем на отдельные на зависимые части. Например кнопка включает лампу. В программе это реализуется так
кнопка имеет поле лампа. т.е. реализация кнопки зависит от лампы. Если тип (или код) лампы поменялся, то и часть кода ответственная за кнопку тоже меняется. По крайней мере должна протестироваться. Но можно договориться разделить все устройства которые могут что-то включать (кнопки) и могут быть включены (лампы, двигатели, телевизоры...) и указать как им взаимодействовать.
Т.е. примерно так:
Кнопка управляет устройствами.
Устройство должно иметь метод "включить".
Лампы, телевизоры, двигатели должны реализовать это метод у себя.
Итого одна и та же кнопка (без изменения кода) управляет целой группой разнородный устройств (но реализующих общие правила взаимодействия)

По картинкам:
у нас есть объекты
связь 0, связь 1, ...связь 3
так же объект шина из связей.
общее для них это они все имеют имя.
также они имеют некоторые правила передачи сигналов.
Это дает нам два класса Net и Bus. Кроме того Bus включает в себя много Net.
Далее хотелось бы , что бы эти классы были независимы от правил. т.е что бы правила мы могли назначать сами. возможно динамически. Поэтому net и bus имеют метод назначающий правила rule (с общим интерфейсом) (которые можно менять, и не менять реализацию net, bus ).
Итого Выделили общие свойства из net, bus в абстрактный класс AbstractNet. bus включает много net. Вынесли правила (которые будут часто меняться и которые мы возможно еще не знаем) за общий интерфейс.
примерно так. упрощенно.