А если у нас система где почти каждый запрос и так дорогой, потому что идёт обращение в базу со сложным поиском, то мы можем пренебречь деталями
Более того, описанное выше никак не отменяет того, что при обработке запроса надо последовательно сделать несколько шагов: залоггировать, проверить, выставить атрибуты и пробросить туда, где запрос и будет обработан (например в дочерний процесс, что ещё добавляет времени)
По-моему нет никакого универсального правила типа "миддлвари антипаттерн"
Да и сами миддлвари, кстати, можно как цепочку обязанностей рассматривать, а можно как builder. И в последнем случае последовательность кажется логичной и необходимой
При этом я согласен с Тимуром, навешивание мусора в req и res (туда, наверное, особенно) это не очень хорошо. Но опять же, универсального правила нет. А миддлварь и вовсе может не навешивать ничего в объект запроса, а формировать свой объект, который идёт рядом с запросом
Проблема в том, что принцип мидлваров способствует написанию бизнес-логики на обработчиках и перемешиванию бизнес-логики с системным кодом. Да, так не обязательно делать, но так мы видим, что так делают в 100% случаев минус исчезающе малое кол-во. Это благорядя тому, что у людей нет знания CS, парадигм, паттернов, нет опыта, а есть только 5 минутные обучающие видео, в которых все делается прямо на мидлварах и на примесях. А я наоборот, предлагаю разделить системное программирование и прикладное. Все вещи, которые нужны всегда, как то логирование, слой доступа к данным и пул запросов к данным, парсинг http заголовков, валидация, куки, безопасность и прочее - это явно задачи фреймворка и эти функции не должны кишками вперед торчать к разработчику, чтоб он их прикручивал в каждом проекте, а нужно их только конфигурировать. А бизнес-логика должна быть в виде контрактов или интерфейсов (набор методов и строго описанные типы данных на вход и выход). В этой картине нет места мидлварам.