Абсолютно понимаю автора, он цитирует определение замыкания, а ему в ответ - определения не нужны, они лишь путают. Он спрашивает, а как тогда? Ему кто про мусорщик, кто про стек, и у него создается ощущение, что сами не могут договориться. Но кроме этого, автор прав, его функция - замыкание.
Замыкания везде работают одинаково. Если функция содержит ссылки на переменные объявленные вне тела этой функции, и которые не являются ее параметрами - это и есть замыкание. Что значит фраза - все функции в javascript - замыкания? Дело в том, что в других языках область видимости может просто не позволить обращаться к внешним переменным, в таких языках функция не будет замыканием, но может быть возможность превратить функцию в замыкание через специальный синтаксис. В javascript таких манипуляций не нужно, поэтому в нем любая функция - замыкание.
Т.е. замыкание это возможность в функции создать ссылки на внешние переменные. А здесь уже как следствие, работа мусорщика, если есть рабочая ссылка, то объект не уничтожается, а в приведенных примерах с 2 функциями она рабочая, так как можно получить доступ из корневого объекта, что удовлетворяет требованиям алгоритма mark-and-sweap. Но это следствие, а не принцип работы замыкания.
Поэтому автор абсолютно прав - его функция это замыкание. Потому что ни в одном определении замыкания нет никаких упоминаний о мусорщике, а значит разницы нет на какие внешние данные ссылаться.
Другое дело, все хотят видеть не замыкание, а его хитрое использование, а именно сохранение ссылки объявленной в замыкании при уничтожении ссылки во внешней функции. Не надо считать собеседующего бездарем, если бы вы ему объяснили свою точку зрения, он вполне мог бы и согласиться, хотя и не факт, многие собеседования проходят в виде допроса, что говорит о неадекватности или о слабой квалификации собеседующего, в такие конторы не стоит идти.

Можно. Но, например, когда проект начнет работать вам понадобится добавить новую фичу, а следовательно у вас появится 2 версии и нужно будет их как-то легко разделять. Пока вы будете делать эту новую фичу, нужно будет сделать еще одну побыстрее, уже 3 версии. Можно наделать отдельные директории и переключаться между ними, использовать внешние утилиты сравнения, а можно использовать git.
Когда через год понадобится разобраться, а зачем так было сделано, можно найти коммит, в рамках которого было внесено изменение и понять зачем. Еще лучше, если коммиты связаны с тасками в системе управления проектом.
Когда наскучит вручную таскать код на сервер. Когда устанешь копировать файлики между версиями для переноса функционала. Когда все сломал, и понимаешь, что легко бы нашел причину, если бы фиксировал предыдущее стабильное состояние. И это только то, что первое приходит в голову.