Из статьи следует, что ключевыми вещами для блока они считают
- обеспечение возможности переиспользования кода бизнес логики на разных платформах, но это задача (отделение бизнес логики)  большинства архитектур, так что преимуществом блока это нельзя считать. Более того, они предлагают рассматривать блок как viewmodel.
- использование стримов для нотификации UI об изменениях стейта. В этом отличие от provider с его ChangeNotifier. Вот было бы интересно их подробное сравнение по этому моменту.
Других особенностей блока как архитектуры там не описывается

Вот из таблички, setState - то что тут под ним понимают, это скорее отсутсвие архитектуры, тяп-ляп как придется.

В ScopedModel - примерно также, сюда же можно записать и Provider как "архитектура"

Без setState не обойтись для локального стейта. В конечном итоге все к нему сводится.

Ну что именно ты хочешь понять?

Плюсы минусы использования стримов для нотификации UI по сравнению с changenotifier

стейт менеджмент необходим если на проекте больше чем 1 человек и проект планирует развиваться

Тут скорее твой вопрос не "почему блок", твой вопрос скорее "почему стейтменеджер"

Если тяп ляп то ты можешь и репозиторий сделать синглтоном и дергать его откудахошь

стейт менеджмент позволяет вам хранить состояние приложения в одном месте