ну да
вам же через этот use прилетает пачка методов, уже реализованных(handle_info на любое сообщение, например)
какие-то надо реализовать по контракту(not implemented)
это можно расширять, можно не трогать

это не антипаттерн, верно?

Инстансы объектов могут иметь прототип, почему нет? и структуры данных тоже могут иметь прототип? Так в чём разница?
А в том, что прототипы инстансов объектов (классы) можно наследовать друг от друга. И наследование это используется как попытка изобразить полиморфизм. Получается ООП - это про полиморфизм через подмену исполнителя.
Плата за такой вид полиморфизма - избыточная сложность связей в коде. ООП напрямую противоречит SRP.

собственно такие же макросы, как use GenServer я и писал
какие-то методы общие, какие-то можно или нужно переопределять
и где здесь антипаттерн?

много текста, много неверно

вообще в любом функциональном языке есть ООП, потому что объект - это замыкание, которое живёт в куче

:)

чтобы подмена исполнителя ничего не разорвала должен быть LSP соблюдён
а это отдельное требование, и оно общее для разработки

Можно, но я не уверен, что это сильно спасает. У меня вот сейчас есть проект, там навернули hfsm(hierarchical) поверх gen_statem. Я не знаю, что там было до этого изменения, но и после него я лично нихера не понимаю.

ни разу не держал больших стейтмашин в проде
правильно понимаю, что там от количества переходов должна крыша ехать?

программирование сложное

Да, объекты - это замыкания для бедных и наоборот.
Но мы не про это сейчас, а про известного всем голема с классовым наследованием.

иногда лучше явные большие стейтмашины, чем неявные

Угу. Код очень теряет прозрачность.

если это бпмн, получается, что картинка со стрелочками в качестве документации помогает?

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

А причём тут переизобретание OOP ? Не приплетайте интерфейсы и наследование к OOP

с бпмн по моим ощущениям пока основная проблема в том, что в него забыли встроить DSL, и его приходится додумывать самому
язык описания данных в виде XSD там ещё худо-бедно присобачен, а вот

скоро мы всё же выясним, что такое ооп

+

Бпмн пытается упростить поддержку вынесением схемы автомата из кода в отдельный артефакт, но все равно выходит посредственно.