Eugene-123

ну например можно эффективно переиспользовать и хранить структуры данных.

вот например сложить 2 списка:
в случае с иммутабельным чтоб создать третий общий список, тебе достаточно только ссылки указать где надо, на первый и второй список - оба списка у тебя будут переиспользоваться, а в память добавится только пару дополнительных ссылок (это вычислительно быстро и требует мало памяти).

в случае с мутабельными списками - тебе нужно создать третий, копируя все элементы первого и второго, что затратно как по времени исполнения, так и по объему хранения.
если ты в мутабельной структуре попробуешь тоже ссылочками сделать новую структуру, у тебя может получится такая ситуация, что уже ПОСЛЕ создания нового списка, при изменении в исходной структуре - эти изменения появятся в твоём новом списке, как неконтролируемое изменение, которое ты не выполнял.
В итоге поскольку в иммутабельных структурах есть гарантии, что они будут не измены, то их можно переиспользовать при создании новых структур данных, мутабельные же нельзя.

А вот сделали бы переменную в private и константный метод для возврата значения и вообще никаких проблем бы не было.

В первом случае вы создали "приватные поля". Можно делать как угодно, но хранить данные в свойствах объекта просто удобнее и наглядее. И нет возможности случайно зацепить внешнюю переменную в замыкание, потом попробуй найди такое.

Меньше кода - меньше ошибок;
Меньше кода быстрее писать;
Меньше кода проще понять;
Использование конструкций языка по их непосредственному назначению лучше выражают намерения;

Первое что приходит в голову:
- при создании экземпляров объекта через замыкания теряются преимущества прототипного наследования (методы объявляются на экземпляре)
- теряется возможность идентификации экземпляра операцией `typeof`

попробуйте написать для ваших объектов юнит-тесты - если это будет легко и удобно - архитектура годная.