Статистические функции нужны там, где функция не использует состояние

То что ты их можешь вызывать глобально из любого места

ничего не мешает и не статические вызывать из любого места

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

Мешают зависимости классов, в котором они находятся + как бы они работают с состоянием

ничего не мешает заинитить чё хочешь и вызывать откуда угодно

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

Если наиболее оптимальное место для этой функции - существующий класс + не требуется состояние, то ничего плохого в статической функции, в целом то, и нет

Со статическими методами классы часто превращаются в GOD-класс из глобальных функций. Модели лары(где и модель, и репа, и логика) с расширениями в виде трейтов - чудный этому пример.

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

Согласен. Просто представлял чистую функцию, без зависимостей и не требующую доступа к состоянию объекта.

Давайте я приведу пример, а вы скажете норм или нет. У меня есть текст, который необходимо каким то образом обработать, я создаю класс TextHelper который кладу в /helpers, и заполняю его статическими методами, когда мне нужна какая либо обработка, создаю в этом классе статический метод, например countSentences

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

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

Рискуешь получить свалку кода. Создай лучше TextTransformer с обычными методами и обрабатывай себе там. Все остальное, в другое место

Но вообще обычно начинают с 1-го класса, а когда он уже разрасстается в размерах, то дробят при необходимости

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

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

Или пакет

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