V Sh.

1. Создать таблицу с тарифами и сроком их действия, где можно будет узнать базовую стоимость за день/месяц/год;
2. Вести таблицу операций пользователей по получению подписок (по какому тарифу и на сколько брали);
3. Заносить информацию по денежным средствам по операциям (п.2) и считать их в абсолютных величинах (если заплатили 650 рублей, то и записывать 650 и т.д.);

Тогда можно будет в любой момент времени узнать:
1. Какие тарифы были доступны;
2. Какие операции производил пользователь;
3. Какие средства крутились в системе в тот или иной момент.

Все зависит от того, как будут использоваться записи в той системе, в которую происходит импорт. Если они собираются хранить эти данные у себя и как-то с ними работать, то им нужен неизменяемый гуид для работы, чтобы они могли нормально обновлять данные. Если это что-то, что не требует обновления, "разовая" информация, то можно и на лету гуиды строить.

Игра - это, в первую очередь, поток данных. И данные эти где-то хранятся. В больших ММОРПГ играх есть отдельные сервера БД для профилей и их состояний, чата, глобального состояния игры. Данные, в таких случаях, берутся напрямую из БД посредством запросов.
Есть и игры, которые хранят данные непосредственно в оперативной памяти приложения (например, в синглтоне). Тогда у класса, отвечающего за хранение данных, должны быть методы для мониторинга (если они нужны) и АПИ для вывода этих данных наружу.
Все зависит от реализации. И да, такая информация доступна только разработчикам или администраторам. Если хотите, чтобы все было красиво, то напишите администрации сервера и спросите могут ли они предоставить вам данные. Если не могут или откажут, то да, нужно будет парсить откуда-нибудь, например, с их сайта.

В чем преимущество автосвойств, если по сути они просто обращаются к автоматически создаваемой переменной, почему бы напрямую не обратиться к переменной без автосвойств? Дело в том, что в любой момент времени при необходимости мы можем развернуть автосвойство в обычное свойство, добавить в него какую-то определенную логику.

Храните в localStorage только данные в каком-нибудь формате, например в массиве объектов. Также напишите функцию, которая будет отрисовывать функционал по заданным данным.
При запуске приложения (перезагрузке страницы) просто запускайте функцию отрисовки из данных из localStorage.
Затем вы сможете расширить свое приложение и получать данные откуда угодно, лишь бы формат был верным (локальный файл, база данных, json и пр.), а функция отрисовки у вас уже будет.

Можно как-то так (на скорую руку):

Можно типа такого, но не уверен, что правильно все уловил:

Скажем так, делать это не обязательно (собирать мусор самому), но если очень нужно (например, в рамках быстродействия), то можно и самому прописать уничтожение объектов (в finally, например).

Почитайте про promise

Вы там почкованием размножаетесь? Или это какое-то распространенное задание?
Есть реализация вот такая, например: такой же вопрос

Никогда не видел объемного и всеохватывающего ТЗ. Обычно это макет и куча правок к нему.