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

Стоит ли оно того в этом случае?Зависит от целей.

1) Мы хотим в 100мб билд уместить. Поэтому в будущем будем ассеты докачивать потом.
2) Хотим потреблять минимум памяти. Адрессеблс позволяют загружать и выгружать относительно удобно ассеты по требованию. Память отъедают только на данный момент нужные ресурсы.

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

Архитектура хз какая, т.к. нигде это не описывают, но точно не хороша. Мегаклассы с мегафункционалом в API(SOLID ? Практики применения хотя бы по стандарту C#? Конечно нет!). А так же кастомизация, с встраиванием посередине - это когда ты видишь очередной интерфейс провайдера чего-то там со строковыми переменными, т.е. с местами куда можно вставить свой код, который что-то поменяет в работе и выполнит ещё какой-то код. Но ты не знаешь что и когда, даже прочитав справку, несколько статей и наконец залезая в исходники, хотя и там может быть просто ссылка на функцию либы.
Так просто не разберёшься, в доке даже нет схем использования, там вообще помимо хелловорда толком ничего нет для прода. Они только-только добавили проверку сертификатов для UnityWebRequest(ещё одно встраивание посередине), ес-но управлять этим нельзя, надеяться на работу без тестов глупо. Но сертификат(кстати, не работает через их интерфейс) - это полумера, об ssl(ssh) они даже и не думали.

Та самая галка только делает ссылку, с помощью которой можно загрузить ассет и вручную его вставить куда нужно, а так же удаляет его из сцены в момент сборки(так же как с ассетбандлами и их поиском зависимостей). По коду это как скачивание картинки из интернета и вставка его в rawimage. Что мешало сделать это автоматически? Вот только если есть файл, на который ссылается пара других бандлов, то вы получите этот файл в обоих бандлах. Тут рекомендуется делать больше бандлов(выделить общее двух бандлов в 3). На деле получается так, что нужно сильно сегрегировать до небольших групп в случае текстур(аудио). А вот в случае скриптов, шейдеров, иногда материалов, получается так, что нужно либо сильно усложнять код загрузки, либо делать мегапак, что серьёзно убивает полезность. Хотя получается и лучше, чем с бандлами.

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

PS: асинки не проблема, уже много лет как стоило научиться ими пользоваться. Я даже удивлён, что они тут используют нативный async и Task, а не AsyncOperation.