Ответ в мультиплатформенности.
Когда пишите на котлине под JVM, вы можете использовать весь набор Java коллекций. Картинка снизу какая-то не полная, как минимум на ней нет Map и MutableMap. Как максимум, раз уж у них java.util.HashSet реализует MutableSet, то и LinkedHashSet, TreeSet - тоже.
Но вообще это не справедливо, если код компилируется под JS или Native.

При преобразованиях меняется только тип ссылки, которая ссылается на объект в памяти. Сам он навсегда остается того же типа, что при создании

Смотря, что вы под этим понимаете. Не думаю, что можно стать "профессиональным котлин разработчиком". Это будет либо мобильная разработка, либо бэкенд. В теории можно и десктоп с фронтом пилить. Но ни в одном из этих случаев знания самого языка не будут решающими.
Если абстрагироваться и от направлений, то всегда будет полезно знать хотя бы распространенные структуры данных, парадигмы (структурная, объектно-ориентированная, функциональная), паттерны, используемые в этих парадигмах, принципы проектирования (SOLID, KISS, YAGNI). Это и к языку не привязано.
Дальше - работа с БД (SQL, NoSQL), HTTP, асинхронность (Coroutines как пример средства реализации асинхронности). Тут придется выбирать библиотеки, доступные для котлина и изучать их.
Это все скорее всего встретится. Но можно под андроид начать приложения делать и с 0. Есть обучающие курсы, в которых все нужное расскажут. По остальным направлениям их меньше, но тоже достаточно. Для бэкенда отправная точка - ktor, для desktop - tornadofx.
Java код вам наверняка придется читать, поэтому хотя бы поверхностно стоит изучить.

Условие "две стороны параллельны, другие две - нет" похоже на оператор xor
Для него таблица истинности
1 1 -> 0
1 0 -> 1
0 1 -> 1
0 0 -> 0
Т.е. можно записать так
isSidesParallel(sideAb, sideCd) ^ isSidesParallel(sideBc, sideDa)
(^ - это xor в джаве)

Вы и так можете проверить проверить ссылку на null, без каких-то дополнительных методов и сущностей. Optional здесь явным образом сообщает, что результат метода может существовать (значение), либо не существовать (null) и не даёт получить значение, не сделав выбор, как обработать ситуацию с его отсутствием. Кроме обычного get() есть ещё методы getOrElse(), позволяющий указать значение по умолчанию, getOrNull().

Ещё бывает удобно сначала выполнить цепочку преобразований над Optional при помощи метода map(), а в конце получить значение любым удобным способом и дальше работать с "чистым" объектом ожидаемого типа.

В kotlinе (раз язык не принципиален) на помощь с борьбой с NPE приходят nullable типы. Каждый класс порождает два типа, к примеру для класса Person это будет Person и Person?. В сигнатурах методов можно явно указать, какой из типов допустим. Если Person?, то компилятор вынудит вас обработать случай с приходом null. Так же вы не сможете вернуть из метода null, если объявили в качестве результата тип Person. Программа просто не скомпилируется. Все ради того, чтобы null не приходил из неожиданных мест, обрабатывался и не ронял программу.