Как я запускал Докер внутри Докера и что из этого получилось

О, здорово!
Вообще полностью согласен с тем, что сборочные пайплайны хорошо ложатся на докер. Это факт. Переносимость. Повторяемость. Насколько это вообще возможно.
DinD — полностью согласен, что лучше, чем проброс демона с хост машины. Почему? Потому что проброс сокета — это натуральный рут-доступ к хостовой машине. Помимо проблем с накоплением временных образов и прочих докеровских сущностей. Я уж не говорю о ситуации, когда нужно пайплайны крутить конкурентно (параллельно). Можно исхитриться и нарезать каждый раз новую сеть, новый набор образов и контейнеров с уникальными названиями, но так себе решение. DinD тут реально помогает. Но у него есть и недостатки. Первый — мы не можем задействовать кэш образов. При каждом пересоздании DinD контейнера он будет обнуляться. С другой стороны это же и являетя преимуществом, т.к. каждый раз мы получаем "чистую" среду. Второй недостаток заключается в производительности. В первую очередь — при работе с файлами. overlay поверх overlay реально тормозит. Другой вопрос, что это не всегда существенно. Можете почитать классическую статью от 2015 года почему DinD — плохо — https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ и сделать свои выводы.

Также я не понял две вещи:

1. запускать докер-демон в фоне, если можно отдельно запустить контейнер с демоном dind, а потом к нему прилинковать контейнер с docker-клиентом, да хоть с хост машины можно ходить в контейнер dind. Так по сути пайплайны gitlab и работают. https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#making-docker-in-docker-builds-faster-with-docker-layer-caching
2. зачем собирать свой кастомный dind образ (а его еще придется поддерживать!!!!), если есть вполне официальный docker:dind, а если он не очень — то есть от гитлаба свой.

Еще момен — рекурсивный (вложенный) dind может быть интересен с академической точки зрения. Но точно — не с практической. Не могу представить реальных кейсов, когда он реально может решить какую-либо задачу эффективно.

docker-compose решает эти проблемы.
Если же есть параллельные билды, то можно использовать lxc + docker-compose, как это делает circleci.

А как насчет Kaniko? Он быстрее.