If you never call .get() on a unique_ptr then you'll be okay. But that's often not a workable design.
No, it isn't. That's flagged by default settings of most static code analysis tools, and it requires explicitly going against the whole point of explicitly assigning ownership of an object.
Which static analysis tools? Can you point me at them? Maybe a sample program demonstrating that it'll throw out up loud warnings when I pass a reference to an member owned by a unique_ptr to another function? Like, are there any static analysis tools that warn on every single string_view parameter?
You're failing to understand that granting access to the raw pointer managed by a std::unique_ptr violates the precondition that the object owned by that smart pointer is managed exclusively by the smart pointer itself.
It's very strange how you fail to get this point when you're trying to complain about C++'s supposedly memory management issues in general, and in this particular case an error sparking from violating these invariants.
Failing to use a smart pointer, to the extent you even have to explicitly ignore errors from static code analyzers to make them, is not a language issue. It's a "pay attention to the big red error messages" issue.
You can't have your cake and eat it too. It makes absolutely no sense to spend so much time and energy mindlessly criticising a programming language to then try to argue that making one of the most basic errors was somehow an acceptable practice when it clearly isn't.