Eloquent прекрасно выполняет свои задачи простой и более-менее эффективной ORM для проектов с CRUD и около таких.
Разумеется частенько нужны запросы посложнее и их выделяют либо в скоупы в самой модели либо в отдельные классы, которые билдят запросы.
Когда задачи становятся еще сложнее, когда нужно уже делить всю нашу модель на read and write части, Eloquent уже начинает подбешивать :) Плюс невозможность отделить логику класса модели от логики её хранения в бд начинает напрягать на любых моделях сложнее одной строки в базе. В итоге в тех проектах, в которых мы хотим отделять Domain логику от всего остального(в том числе базы данных) намного выгоднее отойти от него.
Все эти репозитории нам нужны как раз для этого, чтобы абстрагироваться и отделить логику хранения обьектов доменной логики где-либо. А с элоквентом это практически невозможно. Я это подробно буду разбирать в книжке, которую тут уже отрекламировали - https://leanpub.com/architecture-of-complex-web-ap...

Выделять же классы для некоего query building - вполне нормально для проектов с Eloquent. Вот только не увлекаться желательно. Иногда люди мучаются страшно с этими элоквентовскими билдерами, тогда, когда проще банально написать raw SQL запрос. Обычно это касается всяких отчетов, где много разной интересной агрегации с группировками и т.д.

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

$array[3] = [
    'id' => 3,
    'name' => 'test2'
];

Соответственно "поиск":
$array[$a]

Мне особо не надо юзать Doctrine ORM.

И не надо. Используйте PDO какое-нибудь напрямую. И те самые классы(c findBy*) самому реализовать. Зачем пушкой(доктриной) по воробьям бить?