One of the downsides of the C++ approach is that it makes it more cumbersome to make changes in your code. If you for instance make a trivial change where you change a variable from a stack-allocated object accessed directly via .foo() into a heap-allocated one accessed via ->foo(), you have to either manually change all .foo()s into ->foo()s or do some sort of weird work-around, such as making a separate variable that's a reference to the heap allocated object so that you can keep using those .foo()s. This is all relatively pointless busywork, which also pollutes the commit history with relatively meaningless changes.
There is no sematic difference between passing in a reference and passing in a copy of a smart pointers though.
Yes there is a difference at the call site between taking a reference to an owned thing and taking potential ownership of the thing.
However inside the function block it is noise. Nothing inside the code is semantically different between the two forms, both do work on preexisting data.
Certainly the second version could have a change where it does something with respect to the fact it is a smart pointers, changing what used to be a grabbed pointer to a weak pointer to be more explicit about lifetimes for instance.
However that code change would be just as explicit as long as there aren't any methods on the smart pointer in the auto deref world.
