German Jet

Не рекомендую ничего делать с сайтом. Как бы ни было жалко работу, своя репутация дороже - это на случай, если вы хотите навредить.
Но:

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

2. Сайт смело можно добавлять в свое портфолио и искать другую работу.

3. Деньги жалко, но это всего лишь деньги и всего лишь один из тысяч эпизодов этой жизни. Постарайтесь взять от ситуации больше позитива. Испортить репутацию нехорошей студии можно и позже, когда вы поймете, что никаких других вариантов нет, а вы уже нашли другую работу и там вас оценили.

Возможно ли изучить PHP-фреймворк параллельно разрабатывая на нём проект?

Честно говоря, не представляю, как ещё по другому можно изучать фреймворк, в т.ч. PHP.

плюс ко всему проект должен быть приспособлен к highload.

Тогда с выбором фреймворка, нужно быть поосторожнее. "Не все фломастеры одинаково вкусные".

микросервисы, которые обходились без больших фреймворков даже при основательных нагрузках

Чистый PHP-код, работает быстрее чем любой фреймворк. Я имею в виду, грамотно написанный PHP-код, т.к. в нем отсутствует "лишняя" логика.

Хочу использовать для разработки фреймворк Yii2. В чём вопрос: смогу ли я параллельно его изучая приступить к разработке

Скорее всего да, хотя это очень индивидуально.

и так, чтобы потом 10 раз не пришлось переделывать?

Скорее всего нет, хотя это тоже очень индивидуально.

Может, изучить какой-нибудь микрофреймворк?

Возможно. Зависит от Ваших задач и целей.

Понятное дело, что без правильно настроенного содержимого моей черепной коробки даже с 10-ти летним опытом в Yii не получится, но всё же, поделитесь опытом и дайте совет :)

Ну я обычно с новичками, изучение с CodeIgniter'а начинаю, т.к. он не изобилует всеми новыми фишками и плюшками, и в виду отсутствия таких, казалось бы, ставшими уже стандартом вещей, как например "авторизация" - заставляет их включать голову, а не истерично рыться в поисковике на тему "как включить готовую авторизацию", но мне не редко приходиться работать с людьми, которые не очень хорошо разбираются в PHP, Фреймворках и программировании в целом или веб-разработке в целом. Не многие сходу знают, что такое MVC и так далее, а пытаться объяснить человеку, что такое класс и тут же нагружать его "пространствами имён" или "внедрением зависимостей" (и всем остальным) - не очень продуктивно (как показывает практика). Когда у обучаемого 10 лет опыта за спиной, можно сразу с Laravel/Symfony начинать, как минимум, что такое MVC и всё остальное - объяснять редко приходится, скорее, приходится показывать, "как это сделать тут", а "как надо делать вообще" - обучаемый уже и без меня отлично знает.

P.S. Если Вы напишите больше конкретики, что знаете, что не знаете, что в Вашем понимании HiLoad, какие ресурсы у Вас для этого есть, какие примерно БД и какая примерно задача, какие фреймворки использовали раньше и использовали ли какие-то вообще, на каких языках, какие проекты (теоретически) разрабатывали ранее и т.д. будет гораздо проще дать Вам какую-то более конкретную рекомендацию.

Шаблонизаторы типа Smarty, Twig в 2017 востребованы, если с ними раньше не работал стоит ли смотреть, изучать что бы повысить ценность свою на рынке труда?

Smarty - вряд ли.
Twig - вполне себе актуален, я Вам даже больше скажу, он уже интегрирован "из коробки" в довольно популярную CMS по имени Drupal 8 (т.к. он сделан на базе Symfony) и собственно, в не менее популярный фреймворк под названием Symfony. И, Twig отлично встраивается в очень популярный фреймворк (я имею в виду, в ракурсе PHP-*) под названием Laravel, который в свою очередь так же имеет свой весьма неплохой шаблонизатор, под названием Blade.

Среди прочего, вариация Twig'а есть даже для JS (Node.JS), в качестве альтернативы таким штукам как Pug/Jade например. *По информации одного из наших коллег, такие шаблоны (в JS-вариации интерпретатора) отлично переносятся потом в оригинальный Twig/PHP (имеют хорошую совместимость/переносимость).
*Сам не проверял, но, доверяю словам автора.

Или их нативный php всё же их вытеснил

Из тех шаблонизаторов, что я могу вспомнить, по моему, все "компилируются" (преобразуются) в нативный для системы код (даже Smarty), т.е. если мы говорим про PHP - то соотв. в PHP-код. Парсится шаблон в код не часто и разница в производительности довольно не значительная, в 99% случаев - ей можно принебречь.

или все ушли во Фронтенд шаблонизаторы?

У них обычно немного разные категории задач. Если Вы говорите про шаблонизаторы аля Pug/Jade - то, что из них выходит, в конечный не-JS код, интегрируется плохо. То есть, смысл от этого шаблонизатора только для того, кто делает вёрстку, практической пользы при переносе на PHP-движок (и другие не JS-движки) от него обычно нет, либо очень мало.

Если говорить о чисто клиентских реализациях - генерировать данные на клиенте, в таком объёме, по моему, не кошерно в подавляющем большинстве случаев, с учётом того, что сервер может кэшировать страницу целиком и выдавать сразу готовую (Varnish, например, это если говорить о необходимости высокой производительности), а какой-нибудь полу-мёртвый смартфон, бедолаги, который зайдет на подобный сайт - лопнет от чрезмерного изобилия JS-кода.

Моё понимание такое.
Декларативное программирование - это когда в коде описано что должно получиться, а императивное - когда написано как это сделать. Т.е. в первом случае мы совершенно не интересуемся, каким именно образом машина сделает работу, какие инструкции в каком порядке выполнятся и так далее, мы просто объясняем ей, что хотим увидеть в результате. Примеры декларативных языков - html, css, sql, конфиг nginx. Ещё тут стоит упомянуть функциональные языки (lisp, haskell), программы на них тоже, как правило, являются описанием (декларацией) того "что должно получиться". Ну, короче говоря, мы говорим компьютеру: вот смотри, мне надо чтобы было так, а как ты это сделаешь, мне не интересно. Аналогия такая: у меня есть чертёж бани, я даю его бригаде строителей и уезжаю. Как именно они там будут таскать брёвна, пилить доски и прочее - я не в курсе.
Программируя императивно, мы описываем конкретные шаги, действия и точный порядок, в котором их нужно исполнять. Напрямую руководим процессом, непосредственно отдаём приказания. Примеров масса, большинство популярных языков императивны, в том числе и javascript. Ты пишешь: вот, сделай-ка переменную myVar, потом запиши туда число 5, повторяй это до тех пор, пока что-то не случится... и так далее. Возвращаясь к примеру с баней, ты теперь - начальник бригады, именно говоришь какое бревно куда класть.
Что касается процедурного и объектно ориентированного стилей, это немного о другом. Я бы сказал, что это два разных способа писать императивные программы. В процедурном случае мы организуем код, наши команды (приказы машине) в виде процедур. Процедура - набор команд. Это довольно простой способ организации кода и исторически более ранний. ООП - это чуть более сложный подход к организации кода, когда мы группируем инструкции и данные, которыми они манипулируют, вместе. Объект - это состояние (данные) плюс поведение (набор методов). Но это уже немного другая история.

Можно обернуть эту кастомную логику в виджет и тогда в шаблоне он будет подключаться одной строкой.

MVC - архитектура, которая строится при помощи связки модель-вьюха-контроллер. Но это не значит, что любой класс, который вы захотите создать, должен быть либо вьюхой, либо контроллером, либо моделью. Нет, смотрите по назначению вашего класса - в Yii2 существуют хелперы, которые просто созданы в папке helpers (можете создать свою - frontend/helpers, почему бы и нет?). И вызываются примерно так: ArrayHelper::getValue($array, 'foo.bar.name');
Возможно, ваш класс лучше оформить как сервис - тогда почитайте про сервис-локатор. Читайте документацию, смотрите, как работает сам Yii2 и черпайте решения из него же.
Где именно создавать классы? Решайте сами. Если работаете с advanced-шаблоном, можете создать в common папку components и запилить там свои классы. Не забудьте для них указать namespace common\components; и тогда вы сможете подключать их так:

use common\components\MyClassName;
//...
$api = new MyClassName($someConfig);

frontend и backend отдельные app. И url manager одного app не подозревает о существовании второго. Поэтому нужно в конфиге frontend делать еще один urlManager, который будет знать о backend. И использовать его при формировании ссылки.
Например:

//это стандарный 
        'urlManager' => [
            'class' => 'yii\web\urlManager',
            'enablePrettyUrl' => true,
            'showScriptName' => false,
            'rules' => [],
        ],
//это второй 
        'urlManagerBack' => [
            'class' => 'yii\web\urlManager',
            'baseUrl' => 'http://mybackenddomain.com',
            'enablePrettyUrl' => true,
            'showScriptName' => false,
            'rules' => require(__DIR__ . '/../../backend/config/routes.php'), //тут путь к файлу с rules для backend
        ],

А ссылку формировать так:

Yii::$app->urlManagerBack->createAbsoluteUrl('/'); //ссылка на главную
Yii::$app->urlManagerBack->createUrl(['site/about']); //Ваш пример

Если я правильно понял задачу, то у Вас есть таблица в которой есть название поля (key_feild) и его значение (value), Вам соответственно для пользователей у которых нет разрешения canViewsSite нужно скрыть данные с key_field = 'site'

Тогда непонятно зачем это делать на уровне GridView если можно просто выбрать данные по соответствующим условиям из БД. Например так:

MyModel::find()->where(['not' in, 'key_field', 'site']);

Это, конечно, не совсем то, чего вы спрашиваете, но я бы не стал сохранять имя в hidden, а просто сделал вот так:

...
if form.is_valid():
    comment = form.save(commit=False)
    comment.user = request.user
    comment.save()
...