dom1n1k

72dpi - это соотношение из бумажной типографики. В вебе по стандарту принято 96dpi. По-хорошему, дизайнер должен устанавливать в макетах именно это значение.
https://www.w3.org/Style/Examples/007/units.ru.html
Соответственно, 1px = 0.75pt.
Разумеется, на реальных физических устройствах эти соотношения плавают, но условно принято так.

Либо css-in-js, либо по коду прошлись обфускатором :)

Если общая ширина меню важна для дизайна, то её и нужно фиксировать размером.
А пункты внутри распределять не марджинами (вы же помните, что небольшая систематическая ошибка имеет свойство накапливаться?), а через flex и space-between.

Нет однозначного ответа. Все три варианта могут быть годными в зависимости от логики макета.

Cпецификации W3C.
Да, скучновато. Но получить полное представление о Карузо можно только на живом концерте Карузо, а не от Рабиновича по телефону.

Чистый css знать нужно обязательно. Это видно по огромному количеству дебильных вопросов на Тостере в духе "а как это сделать на бутстрапе?" - и приложена картинка, к которой бутстрап ни в борщ, ни в красную армию. Фреймворки в css - вспомогательный второстепенный инструмент, который иногда помогает, если хорошо подобран под задачу. Но чаще - балласт.

С JS немного сложнее. Там фреймворки более важны и нужны. Но... знать ваниль всё равно нужно. Без ванили это все равно учить иностранный язык готовыми фразами абсолютно без понимания грамматики - в шаблонных ситуациях поможет, но шаг в сторону - и ты мычишь.

Работать будут оба варианта, но более удобны, конечно, манипуляции со свойствами style/weight.
Вариант с отельными именами был популярен несколько лет назад, потому что в те времена это было более кроссбраузерно. Но сегодня уже нет причин так делать.

Не надо верстать, надо двумя растровыми картинками, переключаемыми по медиа-выражению.

Зачем эти полоски верстать? Чтобы что?
Делать их частью картинки, текст поверх, да и всё.
Как вариант, сделать бутерброд из 2 равновеликих картинок - квадрокоптер и все полоски.
Это тот самый случай, когда мудрить нет смысла.

Иконки - крайне желательно.

С фотографиями вопрос спорный, поскольку уже давно неактуальна практика подгонять размер картинки пиксель-в-пиксель под её место на сайте. Когда-то в незапамятные так делали и тому был ряд причин:
- популярность фиксированной и "полуфиксированной" верстки;
- очень строгая экономия трафика;
- некачественные алгоритмы масштабирования в браузерах.
Сейчас должно тянуться (почти) всё и всегда, поэтому зачастую фотографии просто берутся несколько больше, чем нужно (в разумных пределах, конечно), чтобы запас по разрешению покрывал растяжение на большие экраны и ретину.

Но вообще, если заморочиться и через srcset/picture сделать 2-3 версии картинок разного размера - это будет хорошо. Но гемору больше. И выбирать размеры нужно вдумчиво, а то иногда можно получить обратный эффект - траф будет не экономиться, а тратиться наоборот больше.

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

Верстальщики, которые всё это сами видят и понимают... их единицы. Шанс встретить такого в реальной жизни примерно равен шансу отобедать с британской королевой.
99% верстальщиков этого не понимают. В лучшем случае он будет попиксельно снимать размеры с макета и хардкодить их в стилях магическими константами, не понимая логики. В большинстве же случаев он сделает на глазок, а плавающие на плюс-минус несколько (и хорошо если не несколько десятков) пикселей отступы его не смущают. Самое удивительное, что многие программисты на эти погрешности даже не забивают, а искренне не замечают!

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

Для проектов больших ситуация иная - там просто физически не получится охватить и то, и то.

1. Препроцессоры живее всех живых, за исключением малого процента хипстоты.
2. Флекс из категории "можно, но очень осторожно" перешел в категорию "юзать по умолчанию".
3. Ту самую роль "по чуть-чуть и осторожно" заняли гриды.

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

Там ключевой момент не во флексе, а в свойстве object-fit. Потому что идеально подобрать и упаковать разноформатные фото всё равно невозможно - по любому придётся их подрезать.

Не считая отбивки пустыми строками, конец блока не обозначаю никогда, начало - почти никогда. В отличие от JS, где очень часто полезно написать что и как делает функция, в НTML смысл блока, как правило, и так ясен из его класса и/или идентификатора. Достаточно комментировать только какие-то тонкие моменты. В CSS аналогично - комментировать целый блок редко когда нужно, только отдельные правила (зачем оно, откуда взялось значение и тд).

Я сам изрядный консерватор, ко всем модным веяниям отношусь осторожно и со скепсисом... И тем не менее констатирую: на текущий момент flex-box - это мейнстрим. Сегодня на нём уже нужно верстать почти всё, за исключением некоторых специфических случаев, где нужна параноидальная обратная совместимость (например, сайт муниципальной поликлиники).
Лично я перешел на флекс в продакшене в самом конце 2016 года. К тому моменту евангелисты и прочие хипстеры уже минимум год-полтора твердили, что "уже можно, уже пора". А я всё это время осторожно экспериментировал и следил за статистикой.