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

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

collect'ы лучше обрабатывать в классах ViewModel'ей, так как бОльшая часть логики должна находится именно там. Классы View должны отвечать в основном только за отображение данных.

Попадаются "магические константы". Их лучше выносить в отдельные переменные если они повторяются несколько раз, так как если придется их поменять, то придется искать по всему проекту и менять их.

Есть повторяющиеся куски кода, к примеру загрузка изображения через Glide. Лучше такие куски кода выносить в отдельную утилиту или экстеншн и потом переиспользовать во всем проекте

Транзакции в бд лучше делать в самом Dao классе. Так и логика добавления будет в одном месте и можно будет сразу передавать только нужный Dao в класс репозитория, а не весь RecipeDatabase

Не очень ясна необходимость в PreferencesManager'е. Первое на что хотелось бы обратить внимание, это то, что для хранения сортировки вполне достаточно хранить и обновлять в нужной вью модели. Второе, если всё же и использовать preferences, то сами они больше относятся к логике data, поэтому желательно и хранить их в соответсвующей директории. Тоже касается и networkBoundResource. Он используется для работы с data сущностями, получением запросов с сервера и обращению к бд, поэтому его нахождение вне data немного выбивается.

Лишняя вложенность в xml файле с деталями фрагмента. Можно было оставить либо только LinearLayout, либо ConstraintLayout у ScrollView чайлда

Лучше давать названия классам исходя из того, для чего они нужны. К примеру название ViewPagerAdapter не дает информации для чего конкретно нужен данный класс. Лучше переименовать примерно как ImagesAdapter или ImageViewPagerAdapter. Тоже касается и его вьюхолдера

Чтобы избежать лишней вложенности в функциях, в которых почти постоянно используется один элемент, можно писать конструкцию fun sth() = with(useditem) {...}. Важно заметить, что при такой записи будет возвращаться результат последней строчки этой функции