Только вот сейчас на собеседования начинают приходить молодые хипстеры с отдалённым пониманием что такое лямбды кложуры и прочие функциональные истории.

криво написать можно как в функциональном так и в императивном стиле, но дебажить функциональщину хуже

Хипстеры - уже не молодые. На молодых ещё не навесили ярлык

вопрос о драйверах развития и разном IT. То что глубоко зарыто в производстве чуждо мейнстриму IT

Чуждо, потому что интересно изобретать велосипед, а промышленные задачи решать не интересно

Инновации, другой вопрос

это на зумеров-то или на тиктокеров?))

Наверно))

Если приходится прибегать к дебагу, то печаль изначально в любой парадигме. Тесты должны показывать, где ошибка. А REPL в функциональщине позволяет проверять функции на лету.

3d-party либы, окружения, входные данные, сторонние сервисы - от дебага не уйти

плюс дебаг нужен для отладки логических проблем, когда программа делает не то, что ожидалось. А не банальные NPE и т.п

вы серьезно? вы считаете что написать сразу, за заход, в срок, идеальный код (тут еще принято за аксиому, что требования идеальны, и контракты при интеграции прям до мелочей точны всегда)? Так что бы и тех часть кода в шоколаде и делал в точности что нужно?

Внешняя программа, либа, функция? Им доверять нельзя. Сразу на границе проверять на null, exception, пустоту и другие неконсистентности. Можно ещё и автотестами сверху на их код (не свой), чтобы ловить изменения в чужом поведении. ну, я так делаю иногда).
Дебаг нужен чтобы найти проблему, и прекрасен
когда применяется в конкретном обозримом куске функционала. А не когда надо отследить десятки вызовов и логических переходов, нервно куря и паникуя.
Как раз для быстрой локализации: тесты, самопроверки внутри логики, хорошие логи.
Профит в том, что когда код гранулирован,  имеет проверки на границах, обвешан тестами, то сообщение об ошибке с прода довольно быстро приведёт в правильное место, где бяка случилась.
А когда место маленькое, то его легко обвешать новыми автотестами с новыми условиями. И затем пофиксить. Дебаг в таком случае вспомогателен, может быть заменён вызовом проблемного куска в REPL.

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

Сами себе придумали пугало и сами опровергли. Поздравляю с победой. В риторике прием зовётся "соломеное чучело".

риторики не было. свое не опровергал. да и к черту как зовется. в дебатах же чучел нет в приемах. а вот все обвешанное тестами как вы говорите, на код который раз и идеально написали — по пол часа висеть будет и лагать секунды на три в лучшем случае. если вообще вернет нужный результат. Все едино такие обвесы не очистить на проде. А за счет ограниченного времени и идеального захода по написанию, нифига код без обвесов, который писался под них, за заход, норм на проде отработает.

Мы серьёзно считаем, что написать ни идеальный, ни даже приемлемый код за раз невозможно. Тесты помогают в поиске и фиксации особенностей поведения системы. Можно, конечно, и дебагом искать по сотням классов, где таракан сдох. Но мне спокойнее с тестами и короткими методами поиски осуществлять. И быстрее.

*Я не против тестов, TDD хорош. Но только в нужных местах, аккуратно. И обязателен дебаг. В 100% случаях. Иначе сразу — в тех долг его можно записать. Тоже подход, но блин. нее, спасибо. порождать тех долг по умолчанию в каждом куске — так себе формат работы.

Дебаг это поиск бага буквально. Как процесс поиска записать в тех долг?

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

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

А ещё бывают профилировщики, помедитировав в отчёты которых можно найти тормозное место.

В общем, достоинства дебаггера для выявления проблем с перфомансом мне ещё менее очевидно, чем для поиска багов.