да я сам миллион таких вариантов могу придумать)

Тут ты безусловно прав, но чаще всего мы решаем конкретные бизнес-задачи с использованием конкретных инструментов. И если инструмент позволяет легко и дешево задачу решить - почему нет? Даже если это противоречит утверждениям классиков.

да классики не с бухты-барахты это придумали. Разница между клиентом и сотрудником - что клиент может делать всё что угодно по собственной воли, у нас нет никаких вариантов его заставить что-то делать, я могу только предполагать. А сотрудника заставить могу - премии лишу, уволю, нового найму (с клиентами так нельзя). И получается мы либо ответственность за наш процесс отдаём на клиента (а ему пофиг, у него своих забот хватает )и они могут зависать, работать не так как мы бы хотели, владелец процесса не сможет обеспечить метрики нужные из-за клиентской природы, либо облкдаываем это миллионом уведомлений, посказок, таймеров, откатов транзакций и всем таким, что не имеет отношения к сути бизнес-процесса, а является способом полечить неверное понимание роли в процессе.  Ну а технически понятно, можно вместо БД файлики в самбе хранить или там вместо кафки через почту в gmail общаться, легко и дешево )

Процесс обслуживания клиента разве не предполагает участие клиента? И от действий клиента в том числе зависит дальнейшее продвижение по шагам процесса. Например, предоставление каких-либо документов. Сейчас тренд на самообслуживание, т.е. часть задач клиент выполняет сам.
Но мы, следуя заветам классиков, говорим - нет, назначать задачу на клиента нельзя. И тогда мы делаем вместо юзер-таски какую-нибудь экстернал-таску и в ней, по сути, реализуем поведение юзер такси. И в чем тут выигрыш для процесса, для бизнеса?
Ключевой вопрос - клиент участник процесса, или нет. Если участник - вот тебе таска, Если нет - то и вопроса нет.
И речь не о нетрадиционных использованиях священной коровы Camunda.

нет конечно, клиент не участник бизнес-процесса

он находится снаружи процесса и всё что мы можем - это реагировать на его действия или бездействия

но это не является UserTask в контексте BPMN

с клиентами даже и бизнес-процесс особо не слепить - они могут сказать по формам туда сюда, бросать полузаполненные поля, начинать писать в слак, а заканчивать на мобиле, а так далее

Ну почему же? Он полноправный участник. Мы ему поручаем что-то сделать, чтобы он получил услугу. Когда ты приходишь на почту за посылкой, ты становишься участником процесса выдачи и на тебя назначается задача - продоставить паспорт. И пока ты эту задачу не выполнишь, процесс дальше не двинется.
Утрированные примеры про слак и скакание по формам - это к тому, как построить систему обслуживания клиента. Можно правильно, а можно нет.

ну и что делать с процессом, который завис на "предоставить паспорт"?

usertask в BPMN предполагает 100% возможность и необходимость его выполнением

Он должен быть выведен их этого состояни по времени ожидания. Например, тетенька отложит обслуживание тебя или прервет процесс, крикнув "Следующий".

сервис таски почему-то на 100% выполняются или падают к экспшенами

а вот такой юзер таск чот встал хрен пойми почему

хотя наследуются от одного типа - acitvity

поэтому пойду ка я все их обложу таймерами или conditional eventами)

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

Именно так, но попадание под автобус незакладывается в бизнес-процесс и решается на другом уровне управления

да я тож не вижу, просто профессионалы в ассоциации договорились так не делать)

Почему же не закладывается. Всякие KPI по времени выполнения задачи, разве это не оно? Или для тебя принципиально, каким способом этот KPI контролируется, если метрики в отчете, то это процессно, а если таймер на юзер-таске, то это не по фен-шую?