dom1n1k

Ответ "нет" в обоих случаях.
Единицы вьюпорта бывают очень полезны в отдельных случаях, но переводить на них всё целиком и особенно шрифты бессмысленно.
Вариант с font-size: calc(vw + px) [гуглить по словам "css шлюзы", если не знаете что это такое] - более-менее приемлем, но тоже не универсален на 100%.

Весь Бутстрап вы не то что за 2 часа, а даже за 2 недели не напишете. Точнее, напишете черновое нечто, а потом еще неизвестно сколько времени баги ловить будете. И где-то через месяцок-другой дебага поймете, что пора делать глобальный рефакторинг :)

Хотя упоминание гридов заставляет заподозрить, что вам нужна не вся библиотека, а только сетка? Если так, то да, можно и самому написать все эти col-1 и т.д.

По поводу кастомизации - Бутстрап ей поддается хорошо, только если ваши изменения укладываются в рамки переопределения переменных: https://github.com/twbs/bootstrap/blob/master/scss...
И очень плохо, если что-то сложнее/глубже (в силу архитектуры и исторических причин).

В целом хорошо. Конечно, есть шероховатости, но ничего критичного.

1. Ширина блоков с мороженым ограничивается через max-width, отчего при некоторых размерах окна они слипаются. Нужно сделать нормальные отступы между ними.

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

3. Название мороженного это ссылка (логично), но при ховере на блок подчеркивание пропадает почему-то.

4. Не нужно использовать слишком общие классы типа .header или .modal. В почти любом сайте у вас будет несколько хедеров и так далее. Нужно конретизировать, даже если прямо сейчас это вроде бы пока не нужно: page-header, modal-header, section-header, catalog-header и т.п.

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

6. В слайдере перелистывание только по "биатлону"? Для мобилы это мелко, нужен свайп или боковые кнопки.

7. Я сделал бы кнопки тегом [button], а не [a]

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

Это то что я нашел за несколько минут.

Найти работу однозначно можно, потому что качество результата уже сейчас выше, чем у большинства людей, которые называют себя верстальщиками. Самое главное - видно, что автор обладает аккуратностью и вниманием к деталям. Это просто бич огромной части разрабов! Всякие scss и gulp-ы они значит изучили, а разницу между 10 и 15 пикселями не видят...

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

Если вы походите по популярным интернет-магазинам, то с удивлением обнаружите, что большинство из них до сих пор сверстано флоатами или инлайн-блоками! Потому что там каждый посетитель - это живые деньги. И более того, нередко именно консервативная и не очень грамотная в IT аудитория наиболее платежеспособна.
Так что если вы пишете коммерческий e-commerce движок, который потом будет использоваться в тысячах магазинов и ворочать миллионами долларов - вполне стоит.

Другой пример, когда я параноидально боролся бы за максимальную кроссбразерность - сайт муниципальной поликлиники. На него должна зайти любая старушка с подаренного внуками пентиума.

В остальных случаях на надо.

Использую Less и Scss.
Scss мощнее, но некоторые аспекты языка реализованы на удивление коряво.
Less более ограничен по возможностям, но имхо на типовом коде удобнее и для небольших проектов его почти всегда достаточно.

Почему, раз всё началось с DRY, все равно вернулись к обычному цсс "избыточному" синтаксису?

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

тогда как препроцессинг немного более муторный, чем просто возможность подключить жаваскрипт, и отдавать как есть на клиента?

Компиляция less-стилей на клиенте - это фича сугубо для разработки! На продакшене про неё нужно забыть, совсем и напрочь.

Есть ли вообще смысл использовать Stylus?

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

Глобальное обнуление может привести (подчеркиваю - может, но это не точно) к проблемам, если в дальнейшем на сайте планируется "неконтролируемый" контент. Обычно это то, что загружает контент-менеджер через админку цмс.
Если такое не планируется, то глобальное обнуление работает без проблем.
Часто можно встретить аргумент, мол, селектор-звездочка медленный. Это чушь.

Да, есть такое. Читайте литературу по шрифтам.
Ключевые слова: литера, кегль, очко, заплечики, x-height, cap-height.

Больше всего на визуальное восприятие размера текста влияет x-height. И она действительно может плавать в широких пределах. Выхода три:
1. Подгонять на глаз.
2. Если у вас фиксированный набор шрифтов, прописать их высоты в некий LUT.
3. Вытаскивать метрику из шрифтового файла программным способом.

Но последний случай довольно замороченный, там придется погружаться в кучу еще других метрик.
Вот можно взглянуть: https://fontdrop.info/ (вкладка "data")

Внимание, вопрос: зачем тут изгаляться с псевдоэлементами, если можно (и нужно!) скруглить и стилизовать сам элемент?

Убрать из списка варианты local()

Скролл-бар