Ownership of the pointer isn't an issue/topic here
It is. That's what Zipster was trying to explain. It is perfectly fine to pass a reference to an unique pointer from a technical point of view. It just isn't 100% "correct" in semantics.
A unique pointer not only manages the resource but also communicates that your intent is there shall be exactly one such pointer which owns the resource. You can move it, but not copy. If you move it, you must do it explicitly, and you thereby communicate to the human reader that you wish to transfer ownership.
When you create a reference, you're cheating. You are creating a "copy" without creating one. The reference is merely an alias with a different name, sure, so technically this is perfectly correct. But it
looks like something different.
I don't want to pass an actual unique_ptr in these cases.
You cannot even do that even if you wanted, the class is designed to not allow this (that's the major difference to it's predecessor auto_ptr). You can only move the unique pointer, which however turns the function into a sink.
Now you can be especially devious and create a reference to the unique pointer, and then move the unique pointer to your function. That, too, is perfectly "correct" (until you access the reference). Only just, when the function returns, the unique pointer that your reference aliases will have been destroyed. Good luck trying to debug that, it might even accidentially work for a while.
Long story short: References to smart pointers are not the most awesome idea in the world.