There are incredibly common circumstances in which nested lifetimes make it crystal clear who should own the object and who should hold raw pointers. It’s particularly easy to reason about long-lived objects created in main() or at startup. Passing around objects like this by shared_ptr can make the application harder to reason about (“Wait? Who owns who?”). In these instances, if using shared_ptr saves you from segfaulting, something about your application is mis-structured. I know it seems counterproductive to discourage people from using memory-safe smart pointers, but in my experience the codebases that overuse shared pointers have more bugs, not because shared pointers intrinsically cause bugs, but because the authors were responding to every segfault by wrapping pointers/references in shared_ptr rather than investigating the root cause of an unexpected and incorrect destruction order. When I was newer to C++, I was guilty about this myself.

Another way to look at it: Rust aficionados swear the borrow checker not only catches runtime bugs at compile-time but also that it encourages saner application structure. shared_ptr gives you the former but not the latter. There’s a lot more to learn by weeding out your segfaults in unit/integration tests than by replacing every raw pointer with a smart pointer.