Иван В

Задай свойства padding и background для <table>, а не для <a>.
И проверяй поддерживает ли почтовый клиент то или иное CSS свойство:
https://www.campaignmonitor.com/css/box-model/padding/

Проблема в том, что у тебя в SCSS нет стилей для "активного" состояния меню.

При клике на бургер, добавляются классы "active" на кнопке и шапке.
В случае с кнопкой, комбинация классов "header-btn" и "active"прописана в стилях и приводит к внешним изменениям кнопки.
Но стилей для комбинации "header" и "active" у тебя нет. По этому меню "не работает".

Или же можно вообще обойтись без папок desktop.blocks и touch.blocks и просто и создать папку blocks

Да, так проще и удобнее.

...и там создать media.scss и именно для header-а прописать свойства для адаптива и через webpack подключить ее?

А вот тут лишнее усложнение. Медиазапросы можно прописать в header.scss. Отдельный media.scss не нужен.
1) если есть желание делать по БЭМ, то в документации вполне подробно написано про варианты файловой струкртуры. Про отдельные файлы со стилями медиазапросов там нет.
2) отпадает вопрос с Webpack.
3) нет 100% правильного варианта, делай чтобы тебе и тем кто будет работать с твоим кодом было удобно поддерживать проект.

Зачем доверять? Составьте договор, пропишите обязанности. Договоритесь, например, в каком виде давать ТЗ, приоритетность задач и что считать успешной работой. И для работы с сайтом разграничьте права.
В общем, поместите человека в рамки, в которых он при желании не сможет нанести существенный вред.

В css можно обратиться к соседнему элементу через "+". Он также работает в styled-components.

export const NavIcon = styled.svg`
  font-size: 20px;
  margin-right: 15px;
  color: inherit;
  &:hover {
    color: #000;
    cursor: pointer;
  }

  + ${SearchField} {
    ....
  }

Бесплатной части тренажеров html academy вполне хватит. Потом просто гуглишь макеты на figma и верстаешь для портфолио.

interface Counter {
   counter: number;
}

const arr: Counter[] = [{counter:120}, {counter:220}];

const res = arr.reduce((acc: number, cur: Counter) => {
    return acc  + cur.counter;
}, 0);

1) Если вы видите, что в вакансиях часто встречается требование знать ту или иную технологию, то конечно изучайте и используйте.
2) Если лично вам нравится технология, изучайте и используйте в личных проектах.

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

Потому что нормальный верстальщик это всегда уже фронтенд разработчик. Поясню.
Нормальный верстальщик:
1) работат быстро, потому что может автоматизировать свою работу с помощью сборщиков и бандлеров, а также препроцессоров для html и css.
2) работает с популярными js фреймворками типа React, Vue и т.д.
3) способен разобраться с api готовых интерактивных элементов (условные гугл карты, слайдеры и прочее), чтобы кастомизировать их по запросу заказчика.

Без всего этого, верстальщик будет долго выдавать голую мертвую верстку в файликах html\css, а это реально ни кому сейчас не нужно.

Вы неверно выводите данные.
Запись {user.movieName} работала бы, если бы user был бы объектом:

user = { 
   movieName: "", 
   movieReview: ""
}

Но судя по консоли, стейт "user" - это массив из одного объекта.

user = [{ 
   movieName: "", 
   movieReview: ""
}]

Следовательно, вывести данные можно обратившись к массиву по индексу {user[0].movieName}.
Обратите внимание, что в работающем примере, прежде чем вывести данные {user.movieName}, массив users "мэпится" {users.map((user, index) => (...)}

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

Тут можно обойтись чистым CSS.

Что должно быть в теге nav?

В теге nav должна быть навигация (ссылки).

Как вы обычно называете эти блоки? По простому типо main-nav__left (меню) и main-nav__right (корзина, личный кабинет, поиск и т.д.). Или как-то иначе?

Из названия элемента должно быть понятно, что это за элемент, а не его свойство.
(хорошо: nav__basket, nav__link, nav__search, плохо: nav__top, nav__last, nav__blue)

Если это не является частью тега nav или является его частью, можно ли называть такие элементы, как поиск или личный кабинет, как отдельные блоки?

Блоки можно вкладывать в Блоки, это нормально.

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

Если что-то можно переиспользовать в другой части страницы - это Блок. Если теряется смысл вне контекста - это Элемент.

1) Выбирайте популярный стэк (например, анализируя вакансии) вместо перечисленных вариантов.
Вот это явно какая-то экзотика:

C# + Excel
JS + НTML + Google Apps Script

2) Выбрав стэк придумайте как на нем сделать что-то полезное на работе
3) Убедите начальника выделить вам время на проект
4) Теперь есть официальный повод чтобы вам разблокировали нужные ресурсы
5) Спокойно пилите проект параллельно изучая нужный стэк
6) Допилив проект и введя его в эксплуатацию, вы получили коммерческий опыт, можно искать новую работу :)

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