Anatoly MoskovskyЕсли программа многопоточная, то возврат ссылки (а не копии) создает точку, когда объект может быть уничтожен между возвратом и присвоением его в копию.
Поэтому, если объект используется в нескольких потоках, то ссылки использовать нельзя (кроме случаев когда вы другими способами гарантируете время жизни объекта).
Создание же копии смартуказателя это атомарная операция и гарантирует что другой поток не уничтожит объект.Будет ли разрушен последний владеющий указатель до того, как будет создана его новая копия на стеке при передачи по значению или до того, как будет создана его новая копия в вызывающей программе при передаче по ссылке - не имеет значения . В любом случае, такие нюансы приходится тщательно программировать ручками через атомарные функции блокировки ресурса вплоть до передачи еще одного параметра, указывающего, освобождать ли ресурс сразу или удерживать до последующего обращения к нему.

OoCcПерефразирую. Передавать по ссылке в другой контекст исполнения не рекомендуется.Да, не рекомендуется, если ничего не знаешь о volatile, барьерах компилятора и кэша.

CEMb, конечно! Барьеры доступа к памяти в Linux
Акцент сделан на Linux, но в действительности, основная информация подходит для всех платформ.

CEMb, еще:
Intel® 64 Architecture Memory Ordering White Paper
А как же всё-таки работает многопоточность? Часть I: синхронизация
А как же всё-таки работает многопоточность? Часть II: memory ordering

Ынтырпрайзыч(тм)из-за таких вот страдальцев по производительности в ПО обнаруживаются бесконечные дыры. С/С++-жулики не там оптимизируют, они только писчу кибертеррористам дают. Страдайте дальше от лишних 3 инструкций..Не болтайте ерундой!
Если вам в вашей программе не нужна хорошая оптимизация для максимальной производительности, никто не мешает использовать Java или Csharp, где контролируется каждый чих и не надо следить за удалением ненужных объектов. Это лишь означает, что не C/C++ - жулики, а вы выбрали неподходящий для себя инструмент.