Aleksei Podgaev

Из того, что не упомянули явно, можно ещё упомянуть хорошее понимание работы HTTP протокола (заголовки, POST/GET и пр.) ну и по возможности другие полезные протоколы: POP/SMTP например. Это особенно важно для работы со сторонними API, что сейчас в тренде. Ну и cURL обязательно прикрутите к PHP-сборке и попробуйте - на мой взгляд самый удобный инструмент для общения со сторонними ресурсами.

Я не смог решить эту проблему и перенёс все диалоги на отдельные страницы. Так получилось даже красивее - диалоговые окна съедали довольно много простраства на небольших экранах смартфонов.

Если не хочется показывать алгоритм расчёта, то, конечно, только вариант 2. Даже если js-файл с алгоритмом как-то минифицировать, всё равно найдётся умелец, который его "дизассемблирует".
Во втором варианте я не совсем понял, что понимается по "оперативной памятью", но полагаю, что проще всего все необходимые для расчётов данные хранить в сессии на сервере (см. $_SESSION) - так меньше данных придётся передавать от клиента к серверу, а значит и скорость расчёта несколько увеличится. Если какие-то промежуточные данные необходимы клиенту, то можно сохранять их либо в куках, как подсказал автор выше, либо в LocalStorage в DOM, либо, если вы используете jQuery, то в дополнительных атрибутах тегов тех полей, которым эти данные нужны. Посмотрите в сторону функционала jQuery.data(). ;)

Если ты только начинаешь изучать ООП и Javascript, то пробуй применять его во всех своих проектах. Со временем сам поймёшь, где нужны объекты, а где нет. Исходя из моего опыта, чем опытней и профессиональней разработчик, тем меньше в его практике маленьких проектов, не требующих ООП.

Согласен с предыдущим ответом. json_encode/json_decode не меняют структуру данных. Так что нужно написать функцию php (или в БД), которая будет выдавать соответствующим образом структурированный результат.
В примере, указанном тобой, как раз в качестве ответа предлагают подобную функцию. Лично мне тот ответ не нравится, т.к. там прямо в коде прошита структура данных с ключами. Стоит формату чуть-чуть поменяться - всё полетит, придётся всю функцию переписывать - это не очень хороший подход.
Твоя структура в этом плане попроще - обычное дерево. Если никто раньше не ответит, попробую вечерком набросать рекурсивную функцию для обхода этого дерева. Уже раз десять подобные функции писал. В том числе и когда в вузе учился. ;)

Я использую сессионный ключ.
При первичной авторизации клиента сервер генерирует для него уникальный ключ (хэш строку достаточной длинны), который потом клиент использует для доступа к данным - передаёт его серверу с каждым запросом. Можно передавать этот ключ куками, можно напрямую в GET/POST запросе в качестве параметра.
Этот способ относительно прост. Абсолютной защиты, как известно, не существует. Но в связке с другими средствами защиты как регистрацией IP адреса, временем жизни сессии и другими, этот способ даёт достаточно хороший уровень защиты от взлома.

Ну а чем ng-Show не устраивает?
Создаёте массив флагов валидности соразмерный массиву использованному в ng-Repeat и ставите каждому элементу атрибут ng-Show. Примерно как-то так:

<div ng-repeat="item in items" ng-Show="isValid[$index]">
...
</div>

Функция валидации должна ставить соответствующий флаг в истину, когда можно показывать следующее поле.