STL smart pointers are all fun and games until you start using threads, at which point you realize that automagically flipping the (now atomic) counter back and forth behind the scenes every time the pointer can't be safely passed as a reference is a performance disaster.
Manually referencing and de-referencing exactly when needed avoids most of this. Sometimes it's perfectly safe to pass the same reference through several layers without changing the number of references.
As an added bonus YOU get do decide which references, if any, need to support multiple threads.
Reference counted smart pointers are just one of the many smart pointer types. Atomically reference counted smart pointers are a smaller subset of those.
I think the GP was accusing you of "side tracking" by bringing up std::shared_ptr in the first place.
My post above was about how C++ smart-pointers compare favorably to Rust's oft-considered-"unique" ownership/borrowing system. The particular STL features that cause equivalent "compile-time magic" to happen to what you get from Rust's semantics, are those of std::uniq_ptr and std::move, not those of std::shared_ptr. So the value (or lack thereof) of std::shared_ptr, isn't really a knock against the value of the C++ STL smart-pointers collection as a whole—you can entirely ignore the existence of std::shared_ptr (I do!) and still think C++ STL smart-pointers are the cat's pyjamas.
Manually referencing and de-referencing exactly when needed avoids most of this. Sometimes it's perfectly safe to pass the same reference through several layers without changing the number of references.
As an added bonus YOU get do decide which references, if any, need to support multiple threads.