GetX for Flutter. Dependency Injection для частных случаев

А Вы попробуйте с малого, например, с obs/Obx - реактивных состояний.
Как говорится в оригинальной доке:

Если это ваша переменная:

var name = 'Jonatas Borges';

то, чтобы сделать ее реактивной, достаточно добавить obs

var name = 'Jonatas Borges'.obs;

и в UI для реактивного поведения, нужно всего лишь обернуть ее в Obx:

Obx(() => Text("${controller.name}"));

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

И самое главное, вам не надо идти на компромисс между чистотой и принципами ООП. К примеру, чтобы добиться инкапсуляции переменной, не требуется никаких ухищрений (спасибо @AndrewPiterov за решение):

// Делаем переменную приватной
final _name = 'Jonatas Borges'.obs;
// Навешиваем геттер
get name$ => _name.value;
// И сеттер
set name(String value){
  if(value.isNotEmpty){
    _name(value);
  }
}

и все. Реактивность UI не сломается, ничего вообще не надо менять. Obx(() => Text("${controller.name}")) по-прежнему останется реактивным, хотя в других местах кода можно использовать controller.name, как обычную переменную, ведь она таковой и является. Это решение очень изящно реализовано в коде библиотеки, там вообще стоит покопаться для развития.

Не знаю, мб Вы знаете?
Я отнюдь не призываю к использованию Get тех, кто по тем или иным причинам не хочет этого делать. Я раскрываю тему дополнительного удобства для тех, кто им пользуется.

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

При этом библиотека как-то берет на себя много задач, тот же dependency injection, по факту сделаный как сервис локатор, собственная навигация. В целом, библиотека сделана так, чтоб вгрызться в ваш проект и никогда из него уйти, и не понятно, что ждет проект при росте.

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

Ох, пахнуло снобизмом-то как! Наша команда умеет в BuildContext достаточно, чтобы связно объяснить на JobInterview про все три дерева Flutter, про их задачи и  не ляпать антипаттерны типа Widget _someFunc(). Более того, наша команда понимает, что бездумное использование как Get, так и любого другого подхода - это путь в никуда. Наша команда знает, как под капотом устроен, к примеру, Obx, или уже проще - Get.width. Именно поэтому мы никогда не напишем MediaQuery.of(context).size.width, вместо Get.width, потому что чтобы достичь одного и того же результата первый соберет с десяток вызовов, а второй - всего один, чтобы достичь одного и того же результата:
size = window.physicalSize / window.devicePixelRatio.
В нашей команде вполне себе соседствуют BLoC на уровне Model/Logic и GetxControllers/GetxService на уровне View/ViewModel, потому что они вполне себе дружат и каждый выполняет свою роль наилучшим образом, а писать многословные конструкты из flutter_bloc - увольте! Более того, Getx отлично сочетается с rxdart, как ни странно. В нашем инструментарии, как у хорошего строителя (позволю себе аллегорию), есть и дрель, и шуруповерт и перфоратор и даже отверточек набор. Каждый мастер умеет в инструменты, подходящие под контекст (контекст задачи, если будет угодно).
Бездумное следование за авторитетами ничуть не лучше бездумного делания чего-либо. Вы подумайте об этом как-нибудь на ночь.