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

другое дело, если это синглтон и можно быстро и эффективно списать  с клиента 10 раз по 100 баксов вместо одного раза)

Вообще не понял к чему ты, если ты обращаешься к сервису и вызываешь метод списания денег например то разницы вообще нет никакой синглтон или нет, если ты 10 раз обратился то 10 раз и спишется просто при бинде это займет больше ресурсов

к хранению данных в состоянии

Как правило хранить состояния в сервисах плохая практика

замечательно. синглтоны это эффективно по скорости, но это плохая практика. Предлагаю на этом и остановиться

Конфиги != Состояния
Представь ситуацию у тебя сервис оплаты в конфиге у него под сотню параметров, ты 20 раз обращаешься к нему за сеанс и при бинде у тебя 20 раз инициализируется конфиг, хорошо если он простой, но зачастую конфиг может проверять такие вещи как например город клиента и выполнять совсем другую логику инициализации

Конфиги != Состояния
Представь ситуацию у тебя сервис оплаты в конфиге у него под сотню параметров, ты 20 раз обращаешься к нему за сеанс и при бинде у тебя 20 раз инициализируется конфиг, хорошо если он простой, но зачастую конфиг может проверять такие вещи как например город клиента и выполнять совсем другую логику инициализации

ладно. я в работу, высосанные примеры как required, которого нет - это утомительно)
расскажи как-нибудь там потом, как отстрелит тебе ногу синглтон)

Я к слову мог бы привести примеры их жизни где и по 50-100 обращений бывает к одному сервису, особенно если это очередь какая нибудь, но зачем токсичным людям что либо доказывать, у них сервис нужен для одного - двух обращений, только зачем тогда вообще нужен сервис если с 1-2 обращениями справился бы какой нибудь хэлпер со статичными методами ..

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

Как раз таки при синглтоне ты используешь уже созданный экземпляр сервиса, а при бинде ты каждый раз создаешь новый сервис при каждом обращении к нему

> расскажи как это ты по 100 раз создаешь сервис, вместо того чтобы использовать его экземпляр?

ты дурачок или прикидываешься?