Если очень кратко, то потому, что принимающие инфраструктурные решения ребята с Debian видят разницу между «product» и «solution».Осмелюсь предположить, что непонимание такого рода возникает с узкого контекста сравнения. Например, «нечто быстрое, легкое, минималистичное» vs. «монстроидальное раздутое хипстерское эмодзискриптище».
Но думать и рассуждать так — значит, упускать с виду другие немаловажные аспекты, которые из сравнения выпадают. В первую очередь — это пресловутая разница между продуктом («product») и решением («solution»). Продукт, в узком понимании программный продукт — это некое ПО, призванное решать задачу или класс задач. Решение предназначено удовлетворять нужды.
Gogs — продукт, очень хороший по своим объективным качествам. GitLab СE, а тем более EE — полноценное решение.
На основе продукта можно построить решение, и продавать его, предоставляя заказчикам услуги по интеграции и поддержке (и получая неплохой профит, т.к. добавленная стоимость растет), или даже построить на основе продукта платформу. Из близкого мне — Databricks/Cloudera/Hortonworks.
Во многих случаях такой подход вполне оправдан, более того, выгоден и надежен. Gogs можно приспособить для личного git-сервера, или в небольшую организацию — быстро и без особых затрат.
Когда потребность пользователя выше, чем «простое хранение git-репозиториев+элементарные штуки с ним», когда в дискуссии «чем закрыть наши потребности» встречаются вещи как «SLA», «поддержка», «bus factor» — тогда и приходит время рассматривать решения. Комплексы, работающие пусть и не столь быстро на эквивалентном железе, сложнее в установке и настройке, чем «apt install», но покрывающие _все_ необходимые нужды, вплоть до планируемых и будущих, включая интеграцию во всякие сторонние сервисы и платную поддержку.
Очень утрируя, список задач можно вести и на маркерной доске, но есть случаи, когда их отслеживать *необходимо* в JIRA.
