Я придерживаюсь того мнения, что применение в обиходе какого-либо термина, должно нести что-то больше, чем просто название процесса.
Например термин Expression (выражение) в рамках спецификации ECMAScript дает понять, что какая-либо часть языка, которая названа Expression - возвращает результат, который может использовать другой Expression, без необходимости формирования отдельного Statement. ( То есть этот синтаксис, может быть частью другого синтаксиса)
a + b; // Expression; Значит он может быть частью другого Expression
theArr [ a + b ];
Замыканиями в языке JavaScript, пытаются пояснить процессы, которые действительно отвечают, как минимум части теории замыканий. При этом, в самом языке JS существует очень простая для понимания концепция Environments, которая в отличии от Замыканий, полно и со всех сторон описывает ВСЕ части JS языка. В тоже время когда Замыкания, касаются только одного частного случая.
Иными словами, это искусственный в рамках ECMA spec термин, который дублирует часть функциональности другого термина той же спецификации.
Потому, мне хочется настаивать на том, что на каких либо собеседованиях использовать вопросы о замыканиях - порочно. Так как они, провоцируют у соискателя, изучение только той части теории, которой достаточно для ответа. И не больше.
При этом - эта часть формирует ограниченное восприятие как самой теории, так и того что она описывает в части JS.
И если уж спрашивать о замыканиях в JS, то спрашивать ВСЮ теорию, по крайней мере в ее фундаментальной части.
И даже в этом случае я бы бухтел, потому, что это отвлекает от того, как описан язык современной спецификацией. Понимая которую, можно обьяснять ВСЕ типичные вопросы о "странностях" языка, таких как - потеря this как контекста, разницу в поведении для глобального окружения и функционального окружения, let/const vs var и т.д. и т.п.
И, тем более, почему алгоритмы, используемые V8 для оптимизации кода работы с "переменными", работают именно так, а не иначе.