Владимир Т.

Хранить всё в одном глобальном состоянии это одна из хороших практик при использовании Redux в разработке

Кто вам такое сказал?

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

Это правда

ничто не мешает хранить состояние в общем сторе

Чувствуете разницу между "для поддержки и расширения удобно" и "ничего не мешает"?
"Ничего не мешает" вам писать как угодно - но какая в этом будет польза?

ценой за инкапсуляцию мы превращаем компонент в чёрный ящик

Да. и это хорошо

Для ответа на этот вопрос необходимо понять, что такое ассиметричное шифрование.

Краткое объяснение. Ассиметричное шифрование используется для безопасной передачи данных в заведомо небезопасной среде. Используя именно алгоритмы симметричного шифрования, оба участника должны договориться заранее о том, какой ключ использовать, что является потенциально небезопасным, потому что этот ключ можно перехватить и осуществлять атаку типа MITM либо прослушивая, либо подделывая пакеты.

Чаще всего используется алгоритм Диффи-Хэлмана, как наиболее простой. Важно! В чистом виде реализация этого алгоритма уязвима к нескольким видам атак, поэтому часто применяют модифицированные его версии.

https://habr.com/post/326880/

Если ваши коллеги компетентны, то они могут пояснить свою позицию - почему именно они выбрали это решение и что не так в противоположенном варианте.

Если они не могут привести никаких внятных доводов, кроме "мне так нравится" и "в крутой компании Х это используют" - то забейте на их мнение.

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

См. NATS.
Куда как меньше админовского/девопского геморра.

На этот вопрос я бы ответил так: начинать проектирование надо не со схемы базы данных, и не с бизнес-логики. Конечно, я и сам обычно начинаю создание именно с проектирования схемы БД, но в целом тогда, когда предметная область мне знакома и ясна.
Вы создаете приложение, а значит вам необходимо знать и понимать кто будет использовать вашу систему и, главное - какие проблемы будет решать ваш программный продукт. И это очень важно!
Например: вам необходимо автоматизировать деятельность платной библиотеки. Использовать ее будут администратор, сотрудник библиотеки и читатель.
Далее, нам необходимо решить какие сценарии использования (так называемые use case) будет реализовано в нашем приложении, т.е. как эти люди (actor) будут использовать нашу систему.
Администратор - управление сотрудниками библиотеки, учет книг;
Сотрудник библиотеки - выдача книг, возврат книг, продажа абонементов;
Читатель - резервирование книг, продление книг, оплата книг и т.д.

А вот когда мы понимаем, кто и как будет использовать наш программный продукт, тогда мы уже можем приступать к реализации бизнес-слоя. Причем не обязательно, что вам необходимо строить полноценную модель предметной области, вы можете ее не строить, удобный шаблон реализации бизнес-слоя - это сценарий транзакции (Transaction Script).
Если все же решили делать модель предметной области, то тут необходимо решить какая она будет, анемичная (anemic ) или богатая (rich). В первом случае вся логика сосредоточена в сервисах бизнес-слоя, а сами сущности предметной области простые контейнеры данных, которые обычно один в один совпадают со схемой базы данных. Во втором случае, основная логика бизнес-поведения сосредоточена в классах бизнес-сущностей.
Ну как-то так...

1. Описание требований бизнес задач
2. Создание словаря предментой области (схемы domain model, use cases и тд)
3. Проектирование диаграммы классов, базы данных на основе domain_model
4. Реализация классов, бд, интерфейсов
5. Тестирование

п.с 4 можно выполнять паралельно

Все доступно в сети для скачивания:

Прежде чем присвоить, компилятор ищет место присвоения.

someObject - знаю где искать (this), нашел
.another - знаю где искать (someObject), не нашел
.param - не знаю где искать, ошибка

someObject - знаю где искать (this), нашел
.another - знаю где искать (someObject), не нашел

Будет ругаться на то, что param не определено

Подозреваю, что компилятор будет ругаться не на то, что param не определен, а на то, что не определен another (undefined).

var x = document.getElementById("root").getAttribute("some-param");

Можно использовать разные SaaS, они обещают разный SLA.
https://azure.microsoft.com/en-us/pricing/details/...
https://aws.amazon.com/ru/rds/mysql/pricing/
https://cloud.google.com/sql/pricing
w2.cleardb.net/pricing

Но нужно учесть доступность сервисов в зависимости от региона.

Компоненты высшего порядка. Можно оборачивать одним компонентом другой, можно передавать компоненты как props. Директивы очень похожи на компоненты или наоборот, только в react, говоря ангуляр-языком всё из директив)
www.w3ii.com/ru/reactjs/reactjs_higher_order_compo...
https://habrahabr.ru/post/309422/
prgssr.ru/development/komponenty-vysshego-poryadka.html

Например,

const dog = () => ( <Dog /> );
const robotDog = () = > ( <RobotDog dog={ dog } /> );

return (
    <MurderRobotDog dog={ robotDog } />
);

либо

<MurderRobotDog />
     <RobotDog >
         <Dog />
     </ RobotDog >
</ MurderRobotDog>

Можно попробовать соединить три запроса через $or в один мегазапрос. Скорее всего, результат вам придется в нодовском коде ручками разбирать на части, где Васи, где девочки. Есть шанс, что этот второй шаг возможно упростить с помощью aggregation framework.

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