> deadlock-и при многопроцессном варианте работы реализовать гораздо сложнее, чем в многопоточном. Организовать гонку тоже надо умудриться, я даже не представляю как это осуществить не через ж-пу.

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

Это не всегда возможно, вы про идеальное рассуждаете, как физики про идеальный газ или идеальную жидкость. Ресурсы разделяются между процессами довольно часто и это отнюдь не "однозначно плохой дизайн". Несколько процессов (или потоков, в данном случае не важно) зачастую выполняют совершенно разную работу, но при этом в разные моменты своей работы должны взаимодействовать, не только короткими сообщениями. При этом перекачивать друг другу массивы необходимых данных - непроизводительно. Очень наглядный пример - работа серверов БД. Надо по-настоящему одновременно (на многопроцессорных-то системах) обрабатывать несколько запросов от нескольких клиентов. Самое реальное решение - несколько потоков или процессов, выполняющие эту работу (даже не обязательно схема "один запрос-один процесс", можно организовывать очередь запросов к рабочим процессам). Само собой оптимальнее всего кэшировать недавно запрошенную информацию -  держать ее в оперативке. Опять же логично, что каждый процесс не будет держать свой собственный кэш - слишком накладно по памяти и страницы данных, ранее запрошенные одним процессом, могут понадобиться следующему. Следовательно кэш - общая, разделяемая между несколькими процессами область памяти, доступ к которой должен как-то регламентироваться и согласовываться. Это к вопросу о плохом дизайне параллельных систем, использующих общие ресурсы. Вот тут всплывают и понятия примитивов синхронизации - всяких семафоров, мутексов и т.п. А при ошибках программировании  и процессы запросто вогнать в дедлок - процесс A заблокировал семафор №1 и хотел было заблокировать семафор №2. Но процесс B в  этот промежуток времени успел блокировать семафор №2 и потом ему по логике надо было блокировать семафор №1, но он уже блокирован процессом A - вот и клин - каждый процесс до бесконечности ждет освобождения следующего, нужного ему семафора. Процессы и потоки абсолютно равнозначны с точки зрения опасности дедлоков, если они используют общие ресурсы. А отказаться от общих ресурсов зачастую просто невозможно - дело, как говорилось выше, не в плохом дизайне, наверное как раз наоборот - дизайн с отсутствием общих ресурсов в параллельных системах - более редкая ситуация, типа как обработка независимых кусков сцены графической картой или какой-нибудь брутфорс на тысяче компов каждый со своим проверочным диапазоном паролей :)