React. Лёгкий способ бросить курить

Именно так (как вы написали в коде). Насчёт создания функции при каждом рендере — кушайте слона по частям. В крайнем случае обернёте в useCallback.

React. Лёгкий способ бросить курить

Для простоты можете использовать библиотеку "react-portal" - он прикрепляет содержимое к document.body. Это не плохо подойдёт для всплывающих окон. Для сценариев, где layout сложный и прикрепление компонента к document.body не отвечает потребностям, я написал библиотеку "react-jsx-portal" (ссылка). Вторая часть readme на русском. Я думаю многим она подойдёт.

React. Лёгкий способ бросить курить

Я писал в конце про библиотеки для работы с порталами. Это выглядело бы примерно так:

есть список:

const ToDoList = (props) => {
	const { items } = props
  
  const handleDelete = (item) => ...

	return items.map((el) => <ToDo onDelete={handleDelete} {...el} />)
}

и есть запланированное действие:

const ToDo = (props) => {
	const { onDelete, ...el } = props
  const [isAlertOpen, setIsAlertOpen] = useState(false)
  
  ...

	return (
  <div>
  ...
  {isAlertOpen && <Portal>
   <НекийКомпонентАлерт onDelete={() => onDelete(el)} />
</Portal>}
	...
	</div>
  )
}

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

React. Лёгкий способ бросить курить

Если нужно не проводить валидацию только после взаимодействия пользователя с формой, добавьте стейт isTouched

У вас есть два сценария: "пользовательский ввод" и "компонент был смонтирован". Так и опишите их. Поместите в didmount функцию валидации и тогда вам не понадобится в сценарии "пользовательский ввод" проставлять флажок для сценария "компонент был смонтирован". Оба сценария станут короче и изолированнее.

React. Как не стать заложником макета, или пример использования принципа единой ответственности

Полагаю, вы поняли не правильно. Именно про это и шла речь в заключении. Подумайте, какими значениями вы проинициализирете origin и destination, скорее всего null или undefined. Так как вы с бэкенда, вам наверняка знакома статическая типизация. Заставит ли она вас сделать проверку на null, всякий раз когда вы решите обновить точку!? Но если вы уверены, что написали код так, что перед обновлением значения origin/destination там обязательно будут - значит это мёртвый код. Нет гарантии, что другой разработчик не нарушит это хрупкое равновесие и в какой-то момент там будет null, а новое значение просто уйдёт в никуда. Поддерживать такой инвариант очень затратно. Поэтому мы и ушли от подобного глобального состояния. Наш инвариант: компоненты (карта, геокодинг, ...) есть только тогда, когда есть что изменять.

React. Как не стать заложником макета, или пример использования принципа единой ответственности

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

React. Не вглубь, а вширь. Композиция против реальности

Всë в ваших руках. Можете использовать функцию. Можете придумать абсолютно иной способ позиционирования - детали реализации остаются на откуп читателю. Но статья всё же не о том как позиционировать компоненты и не о глубине DOM дерева. Главное, чтобы компонент не напоминал банку кильки, а разбирая конкретный юз кейс, вы видели именно его и ничего лишнего и никак не аффектили все остальные юз кейсы.