"Fine" is probably pushing it, but "not the biggest problem you are likely to have" is probably true. But, like, it's easy to accidentally get yourself into situations where somebody forgot to use std::weak_ptr somewhere and you start leaking memory.
Unless you know you must share objects with multiple potential owners, though, std::unique_ptr is a lot wiser.
Yes, when I wrote:
>but also the value is trivial enough that it doesn't matter when it's destroyed or what it does when it's destroyed"
that precludes the value from having other refcounting pointers that could then create cycles and leak.
If you have a situation where a value needs to be shared between multiple other values, but also the value is trivial enough that it doesn't matter when it's destroyed or what it does when it's destroyed, but also the value is not so trivial that you can copy it instead of using a refcounting pointer, then std::shared_ptr is fine.