Недавно делал похожую задачу, долго возился и в конце пришел к выводу, что если "все" или "большинство" имеет общую связь - то это две базы данных (разные заказчики, разные бд, устанавливаете отдельно, платят отдельно, бизнес очень любит такое, когда дважды платят за одну работу)
Или одна таблица с морфом, где есть имя модели, имя родителя и айди, как с картинками. То есть доступ определяется по наличию морфа, а не проверке через связь. Один раз грузанул с моделями их морфы, а потом чекаешь isset(). По факту в логике вы все равно вытянете модель из БД, и проверив потом морф бросите 403 исключение, вместо того чтобы "Не тянуть совсем".
Другой вопрос методы работающие с пачкой, нечто вроде "дай мне все документы, которые принадлежат мне в рамках такой-то компании". Там я думаю можно в одной функции написать whereHas() и не тянуть все записи, так же как вы бы писали вместо LEFT JOIN - обычный JOIN чтобы в выборку не попало то, что не должно там быть.
Это редкий случай когда лучше обобщить, чем нормализовать. Такой же как и писать action_log в общую таблицу по проекту, или хранить картинки или загруженные файлы по моделям в одной таблице чем создавать под каждую модель. (я просто напомню, что если все таблицы вязать через общее звено (а вот морф это не общее звено, это виртуальная связь не имеющая внешнего ключа), то ваша доктрина будет плакать кровавыми слезами, потому что подразумевает DDD и работу с агрегатом - группой таблиц под задачу) - то есть для нормализованной базы лучше дублировать таблицы под логику, тогда как в этих случаях лучше их обобщать, т.к. контроль доступа штука касающаяся отдельной логики называемой "авторизация", а не каждого элемента логики "по чуть чуть".