Rationale Behind PCL `shared_ptr` Interfaces

Question

Many PCL interfaces accept only shared_ptr<T> arguments (e.g. boost::shared_ptr< PointCloud>). [Aside: that is it boost::shared_ptr and not std::shared_ptr is another issue, but should be fixed in upcoming versions.]

Typically such interfaces are a valid option for multi-threaded applications where object lifetimes need to be managed and prevent shared references objects from going out of scope. However, PCL isn't necessarily used in such a context and this API forces one to create many objects on the heap just to support this API style (and always checking for nullptr).

Is there another rationale that I am missing for why this is so?
For local objects, I now need to create a shared_ptr with a custom nop deleter object just to pass it to the algorithms.