If you have two std::unique_ptr pointing to the same object (address), then you did something wrong!
unique_ptr objects own their pointer uniquely: no other facility shall take care of deleting the object, and thus no other managed pointer should point to its managed object, since as soon as they have to, unique_ptr objects delete their managed object without taking into account whether other pointers still point to the same object or not, and thus leaving any other pointers that point there as pointing to an invalid location.
Also, technically, you could wrap the same "raw" pointer into two distinct unique_ptr objects.
This must not be done, because the first of the two unique_ptr instances that goes out of scope will destroy the object, leaving the other unique_ptr instance with a dangling pointer! Still, you could do that...
It could make sense if there was a custom deleter involved. Maybe there's a device that can be initialized multiple times, but must be uninitialized the same number of times. unique_ptr provides one way to do this.
I think that's one way to look at it, but device could be a third-party thing. I've found this multiple initialization pattern to be fairly common.
In this setup, each unique_ptr assumes a unique responsibility for uninitializing the device. This
is somewhat different than sharing one responsibility across multiple shared_ptrs. And the costs are lower, since this way the reference counting is only done once, by the device.
Maybe a custom scope_guard type would be more suitable. unique_ptr does the job, but it only works for pointer-like resources.