Почему многопоточный пакет JDK называется конкуретным?

Java –разработчика хлебом не корми дай написать многопоточное приложение. И он пишет в ожидании увеличения производительности приложения.

Написав приложение, запустив множество потоков ExecutorService (ForkJoinPool настоящий разработчик не использует по двум причинам: FJP создан какими то людьми из Oracle и вторая причина FJP оттюнингован и работает великолепно), разработчик с удовольствием смотрит на свой многостраничный, плохо документированный, труднопонимаемый код в котором различные потоки делают тривиальные задачи. Вроде быстро. И получается странная картина: с одной стороны кастомное решение управления многопоточным пулом, с другой стороны использование встроенного механизма управления многопоточностью, такое как FJP. В этом случае приложение живет и пожирает ресурсы сразу несколько механизмов многопоточности. И это многоресурсов.

Дальше хуже. Мы же знаем, что синхронизированные коллекции не всегда гарантируют корректную работу в многопоточном режиме. И мы как разработчики вынуждены снова прибегать к синхронизации теперь уже коллекций, которые надо синхронизировать.

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

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

И теперь остается главный вопрос. Действительно ли нам нужна многопоточность если затраты на создание и поддержку не сопоставимы с той производительностью, которую мы ожидаем получить?