Zero-alloc в Go: модный тренд или попытка выдать желаемое за действительное?

Коллеги, навеяло после очередного code review, где мне пытались доказать, что strings.ReplaceAll — это «достаточно быстро». Вопрос не про Rust, где zero-cost абстракции это часть религии. Вопрос про Go, где сборщик мусора вроде как должен решать, а на практике мы ловим 2-3 аллокации на каждый парсинг HTTP-запроса. Я понимаю, когда zero-alloc пилят под high-frequency trading или сетевые шлюзы с миллионами RPS. Но когда я вижу, как разработчик переписывает простой конвертер JSON на sync.Pool и unsafe-касты ради «оптимизации», у меня возникает законный вопрос: вы профилировали, или просто прочитали статью на Хабре? В 90% случаев хватит банального escape analysis и правильного использования buffer pool. Остальное — оверинжиниринг, который потом аукается поддержкой. Собственно, вопрос к сообществу: где ваша личная граница разумного? Когда zero-alloc — это необходимость, а когда — просто способ почесать ЧСВ? У меня pet-проект на Rust, так что я могу позволить себе роскошь не думать о GC. Но в Go я предпочитаю сначала измерить, а потом уже страдать фигней. Заинтересован в аргументированных мнениях, а не «у нас так принято».