batyrmastyr

В ЕС такая же история, причем длится она дольше, чем в РФ.

Так из-за ЕС эта фигня и началась. Принимавшие этот закон чиновники, видимо, считали, что пользователи предпочтут те сайты, где за ними не следят. Получилось как всегда.
А наши делают так либо из-за выхода на европейский рынок, либо по глупости.

Если вам нужно демонстрировать заказчику, то передавайте ему изображение, а не сам сайт:
а) технически простой: приезжаете к нему и даёте тестировать при вас, следите чтобы не скопировал.
б) продвинутый: поднимаете RDP или VNC до своей [виртуальной] машины, на ней рубите исходящие соединения ко всему, кроме вашего сайта (любые порты и протоколы, а то ещё вспомнят времена www4mail).
Чтоб совсем сложно было - ищете скрипты ломающие отладчик браузера, чтобы и в отладчике не посмотрел.

Для чисел хватит и ручной проверки.
Для произвольных строк ручной проверки не хватит по нескольким причинам:
1) Экранировать нужно не пару символов и даже не десяток.
2) Помножим это на разнообразие кодировок и проверку существования пришедших символов в выбранной кодировке ("испорченные биты").
3) Даже подстановки силами PDO иногда не спасают.

Mi 6X и Mi A2 - вообще один и тот же телефон, но на Mi 6X прошивка исключительно китайская, без русского языка и без возможности его добавления (вроде и можно перепрошить, но шанс окирпичить очень высокий).

базовый шрифт не 16px, а какие-нибудь 14.25px±50%

За такое надо исправить должность на "дизагнира". Дробные пиксели все браузеры отображают как хотят: кто-то округлит до целых, кто-то до сотых, как у вас, а кто-то честно отрисует даже 14,674956954px. Добавьте субпиксельное сглаживание и получите кучу вопросов "а что у вас шрифт такой мыльный?".

Реально ли пользователи подстраивают размер шрифта?

Сейчас пользователи могут только всю страницу масштабировать. Особо не пользуются, только если со зрением (у пользователя или создателей сайта) проблема.

Чего точно не стоит делать, так это смешивать пиксели и типографские пункты. Либо {font-size: 1em, line-height: 1.25em}, либо {font-size: 16px, line-height: 20px}. У нас сейчас решили использовать пиксели чтобы не думать, чему будут равны 1,4 пункта, особенно если кому-то приспичит сменить размер шрифта. Хотя лично я считаю допустимым при вёрстке в пикселях иногда использовать em для указания отступов, например, в :first-letter.

В плане сжатия js, в первую очередь нужно ускорять разбор и выполнение кода т.к., условно, 10 кб js могут быть хуже пары мегабайт картинок (https://medium.com/dev-channel/the-cost-of-javascr... ). В общем, Moskus прав - удаление пробелов и комментариев из кода мало что даёт, а удаление ненужного кода + переименование функций и переменных заметно уменьшает размер файла.
Но будьте осторожны: если минификатор идёт дальше и прикидывается архиватором (например, Packer от Dean Edwards's или webpack с его тысячами eval'ов !function(F,Q){for(var B in Q)F[B]=Q[B]}(global,webpackJsonp([0], {"use strict";eval("var __WEBPACK_AM), то вы не ускорите работу, а наоборот добавите тормозов на клиенте.

каким боком нужна вся эта математика и алгоритмы во фронтенде?

Многие инженерные специальности опираются на математику, как на фундамент. Одним из базовых навыков для программиста (который инженер, а не специально обученная обезьяна) является умение оценить вычислительную сложность программы и написать эффективный алгоритм. Из-за медлительности яваскрипта и операций с DOM, а также разбухания объёма клиентского кода вопрос эффективности стоит очень остро.
Вместо sicp можно взять любую другую книгу развивающую мышление + дающую понимание «сколько эта операция будет стоит» - хоть «Искусство программирования» Кнута, хоть «Алгоритмы и структуры данных» Вирта, хоть «Структуры данных и алгоритмы» Ахо, Ульмана и Хопкрофта, хоть кого другого.

Вот несколько примеров, что случается если не оценивать сложность, а то и вовсе «сперва кодить, потом думать»:
24-ядерный CPU, а я не могу сдвинуть курсор,
Один разработчик чуть не «сломал» пакетный менеджер NPM,
Facebook и Google выпустили Yarn, новый менеджер п... (npm писали клинические дебилы - грузить десятки раз один и тот же пакет!),
Ещё на новый год многие любят повесить на сайт падающий снег и почти у всех он отжирает целое ядро процессора, в каждой открытой вкладке, Карл! 8 вкладок и у тебя висит даже Core i7. Но если настольные компы просто подвисают, то ноутбуки и телефоны ещё и аккумы разряжают со страшной скоростью.

Из простых преимуществ постгреса - многие запросы в нём отрабатывают шустрее, можно весьма гибко прописать ограничения на данные (если в поле "а" что-то есть, то в поле "б" может быть только "с"), даже крупному магазину может хватить настроек по-умолчанию при которых база довольствуется смешным объёмом памяти.

Из недостатков по сравнению с Mysql - нет множеств (заменяется массивом перечислений), большая строгость работы (число или перечисление нельзя взять и сравнить со строкой "5 = '5'", нужно привести их к одному типу "5 = '5'::int" или " 5::text = '5'5 ", а ваша обёртка над базой может быть не готова к такому).

В контексте nosql баз данных например вижу преимущества в быстродействии, например, причем на порядок.

Увы, это преимущество скорее всего окажется мифом - сейчас как раз потихоньку выпиливаем MongoDB.
Если говорить про MongoDB, то в моих задачах он работал либо не быстрее мускуля или постгреса при поиске, либо в разы (в 2 - 50 раз) медленнее при записи. При этом Монга жрала 1,5 гига памяти, мускуль - 300 Мб, а постгрес - меньше 15 Мб (да, меньше жалких пятнадцати мегабайт).