Discussion :

[JolyLoic]

Il coute un déréférencement de plus, alors ce n'est rien dans 99% des cas, mais cela peut couter cher sur un tableau de unique_ptr. C'est toujours bon de savoir que il y a tout de même un déréférencement en plus avec std::unique_ptr.
Un mec a fait un article sur ce cout ici

Il ne compare pas la même chose... D'un côté, il passe un pointeur nu par valeur à une fonction, puis appelle une fonction sur l'objet pointé. Dans l'autre cas, il passe à la fonction un unique_ptr par référence, puis appelle la même fonction. Il y a donc deux déréférencements, un pour la référence, un pour le unique_ptr. S'il avait passé son pointeur nu par référence, il aurait eu même code (sauf si le compilateur est capable de mieux optimiser le code plus simple, ce qui reste à mon avis la seule source de différences potentielle de perf entre T* et unique_ptr<T>).

Sachant que passer un unique_ptr par référence à une fonction est assez rare, la manière correcte restant, même en présence d'unique_ptr, de passer un T* quand la fonction utilise l'objet pointé sans interférer avec la durée de vie de ce dernier (cas très courant).

Pointeur nu => unique_ptr
void f(T*p) => void f(T* p) (ou si un jour ça existe void f(observer_ptr<T> p))
void f(T *&p) => void f(unique_ptr<T> &p)

[Luc Hermitte]

La "manière correcte" dans la mesure où la nullité est valide. Si les pré-condition de la fonction disent "avec un objet valide", la référence est la manière correcte.
Au final, tout dépend de la sémantique de la fonction : qu'elle soit puits (unique_ptr), observatrice (et que dans ce cas que la donnée soit optionnelle (optionnal, observer_ptr, raw ptr) ou pas (référence) ), ...