Имел опыт прохождения некоего теста, где обход какого-то там 100 тысяч вложенности массива должен был укладываться в какие-то миллисекунды. Долбался тогда долго, но помню что без ссылок не тащило. Там в итоге получился обход стеком или там очередью не помню уже, но смысл был в том, что вместо того, чтобы "добавлять в очередь" в определенном порядке старые значения менялись на новые избегая операции push()/unset() пытаясь на этом "сэкономить".
Но головняк появляющийся в результате того что код наполняется ссылками куда больший, чем выигрыш на тех условных двух функциях на программу, где придется обходить стотысячную вложенность. Вспоминая, что организовать на пыхе машинные вычисления миллиардов постоянно добавляющихся записей без очередей и отложенной задачи с сохранением исходных данных в текст и обратно оч. затруднительно - эта проблема никогда и не всплывает.
У ссылок скорее другая полезная нагрузка.
В пхп массив это не объект в каком-то смысле, а скаляр. При присваивании его он копируется, как строка.
Бывает нужно получить по пути в массиве элемент, а потом поменять его, не соединяя нечто через $arr[ $a ][ $b ][ $c ], т.к. ваши $a,$b,$c представляют собой строку типа 'hello.foo.bar'. Вот тут удобно вернуть ссылку, воткнуть туда что-то новое, не занимаясь обходом снова и снова. Справедливости ради можно сделать:
[ $a, $b, $c ] = explode('.', $varname);
$arr[ $a ][ $b ][ $c ] = 1;
Но если число уровней переменное - приехали
Ещё ссылки неоценимо помогают с пхпшными замыканиями, которые как известно присваивают не скоуп функции их вызвавшей, а скоуп всего класса или вообще ничего. Передав через use(&$some) в него можно записывать изнутри замыкания, т.к. переменные окружающие внутри будут не видны.
А еще при создании \Closure забыв указать static спереди этот обьект оказывается привязан к замыканию. И потом "совершенно случайно" кто-то вызывает вашу функцию в цикле, которая создает замыкания, та в свою очередь копирует туда обьект (вроде как привязывает ссылку! но внутренние массивы лежащие в protected $property так не думают, а стало быть клонирует), имеющий массив с войной-и-миром занимающий мегабайт, и откуда-то получается 100 мегабайт занятой памяти, потому как 100 колбэков было создано. То есть тут еще кое-что про сборщик мусора надо добавить, что к примеру он не может удалить из памяти обьекты ссылающиеся друг на друга и удалит их только когда наберется некое число их очень большое. Именно эта проблема там и играет. Что при клонировании объектов свойства содержащие скаляры - копируются. В этом свои плюсы, например не надо как JavaScript постоянно изобретать deepClone(), т.к. полезная нагрузка уже является копией, а конкретные обьекты можно перетыкать ручками, но чаще всего это сервисы и они общие для всех экземпляров. Но случайно можно там накопировать делов.
ps. некогда пытался склонировать доктриновскую энтити, ибо задача буквально такой и была - сделать "клон" записи (там были опросы, ответы и варианты ответов). боль связанная с тем, что в доктриновских связях более чем первого уровня живут объекты-ожидалки, которые выдадут данные только если их пнуть - просто незабываема. Они делали оптимизацию, чтобы не тянуть полбазы данных. Но теперь чтобы что-то скопировать - можно сдохнуть.