Свинка Пеппа

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

public function getEntitiesByBatch(int $limit): \Generator
    {
        $expr = $this->createQueryBuilder('s');
        $predicates = $expr->expr()->andX();
        $predicates->add($expr->expr()->isNotNull('s.field1'));
        $predicates->add($expr->expr()->isNotNull('s.field2'));
        $accountState = $expr->expr()->eq('a.field3', 'true');

        $qb = $this->createQueryBuilder('s')
            ->where($predicates)
            ->join('s.account', 'a')
            ->where($accountState)
        ;

        $batches = ceil($qb->select('count(s.id)')->getQuery()->getSingleScalarResult() / $limit);

        for ($batch = 1; $batch <= $batches; ++$batch) {
            yield $this->createQueryBuilder('s')
                ->where($predicates)
                ->join('s.account', 'a')
                ->where($accountState)
                ->setFirstResult($batch * $limit - $limit)
                ->setMaxResults($limit)
                ->getQuery()
                ->toIterable() // тут можно возращать просто массив, но мне нужен итерируемый объект
            ;
        }
    }

Upd 1 А сорян, у вас тут битрикс, может у него есть какие-то дефолтные способы хз. Но общий смысл генераторов от этого не сильно меняется:)

Upd 2 И да, этот код работает в консольном скрипте.

... Хендлер так же каждые 5 секунд опрашивает, но уже не базу, а брокер очередей, на предмет появления новых тасков. Выполняет таск и ставит в базе данных статус "done".

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

В принципе Вы сами описали преимущества — разгрести очередь быстрее, чем сходить в БД. Профит будет тогда, когда появится нагрузка.
Ну и опять же, всё зависит от ЯП, например, на PHP скидывать сообщение в очередь это более-менее устоявшееся production level решение проблемы отсутствия асинхронности и корутин.
А если Ваш ЯП поддерживает асинхронные вызовы и может не блокировать основной поток выполнения, то может быть Вам пока и не нужны очереди.
Еще в очереди скидывают большие задачи, которые точно займут много времени — это всякий рендеринг видео и тому подобные расчёты.

Upd
Корутины в PHP, конечно же есть. Но я их не юзал и сказать про них ничего не могу:(

Можно поиграть с псевдоэлементами, которые будут перекрывать border'a (сами border'a можно сделать с помощью фона контейнера и margin между ячейками, например) и nth-of-type, т.к. белые области симметричны друг другу, но смещены отностительно пересечения ячеек и поэтому ширина псевдоэлементов для каждой n-ой ячейки будет своя..
Можно тупо задать position: relative контейнеру, рамки сверстать самым обычным образом подкрашивая border, а внутрь контейнера поместить пару элеметов c position: absolute и z-index, которые бы играли роль засветки на пересечениях рамок. Очевидно, что для более или менее динамической генерации ячеек этот способ не подходит.
Можно сделать комбинацию из двух этих вариантов.
В общем вопрос "как правильно" сильно зависит от вопроса - "а что это должно быть":)

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

gulp.src(['app/blocks/common/mixins.styl', 'app/blocks/**/*.styl'])
        .pipe(sourcemap.init())
        .pipe(concat('app.styl'))
        .pipe(stylus({
            compress: true,
            'include css': true
        }))
        //some pipe

Статья на хабре