> Это не редкий случай. Это, прежде всего, предсказуемость: по
> ресурсам, по времени ответа и пр. И это - грамотный подход
> к проектированию архитектуры.

Понимаете, не вижу я реальных сценариев в которых Вам нужен миллисекундный доступ к громадному количеству терабайт и на чтение, и на запись.
То есть требовать-то такое могут, но когда начинаешь эти требования разбирать, то оказывается, что они избыточны.
Есть какой-то оперативный объём где это действительно нужно обеспечивать, а всё остальное секционируется на так называемые "тёплые" и "холодные" данные. Всё по ТРИЗ - "Сделать заранее"

>   А в куберы пихать серьёзные statefull приложения - это,
> конечно, можно технически, но... зачем?

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

Да, сейчас это не вполне так - но работа ведётся именно в этом направлении, Вы же сами видите.
А мода сопровождающая эту работу - ну, а куда ж без неё?

> - ЗАЧЕМ? Зачем запихивать туда ВСЁ? Может быть негативные моменты и
> можно обойди какой-то хитрой схемой, но ЗАЧЕМ? ЗАЧЕМ усложнять то, что
> в более простом варианте и так будет отлично работать. Более простом,
> а, значит, более надёжном.

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

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