Is a valid use of raw pointers for things within a class? For example, if I construct an object (and correctly release resources if the object fails to construct) and then provide the correct release in the destructor would this be a valid use? I guess that's the RAII paradigm in a nutshell. Or would you advocate smart pointers even in this scenario?
Using the right smart pointer doesn't cost you anything -- either you need shared ownership and needed a reference-counting pointer anyway, or you have singular ownership and unique_ptr provides exactly that at no cost over raw pointers, but in an absolutely correct, secure, and exception-safe manner. It also provides additional clarity to any code that touches the pointer -- you don't know whether a raw-pointer expresses ownership or not, or whether its shared, etc. With unique_ptr, the type tells you the precise ownership semantics.
I suppose if I need to share a dynamic resource to things outside of the raw pointer containing class then smart pointers become essential. But even general purpose libraries intended for mass consumption avoid smart pointers because there's no hard bound guarantee that the same smart point convention is followed by programs which use different implementations. How then is the problem of detecting resource leaks handled? Is there a method to the madness or are designs/tools up to the task?
Still prefer smart pointers for the reasons above. In particular, even if your RAII-aware object doesn't leak under normal construction/deconstruction, have you also taken the additional steps to ensure that it doesn't leak under exceptions that might occur mid-construction? Have you correctly implemented move semantics?
Regarding other libraries avoiding smart pointers, or having their own versions of them, that's more of a reflection that C++ didn't have standard smart pointers until C++11 (or was it TR1?) -- there was auto_pointer, which was supposed to do the same thing that unique_ptr does today, but they got the design wrong and so it was broken.
Regarding detecting resource leaks, if you use the smart pointers, the only real 'leak' you have to worry about is cyclical references between shared_ptrs, which is precisely why weak_ptr exists.
If there's any doubt, these are genuine questions and not quibbles with the concept of smart pointers. I just haven't been on a large enough project to see what disasters might befall the unwary.
What I hear you saying is that you've never been on a project large enough that manually-managing memory allocation and deallocation has bitten you. That may be true; its easy to get your head around small projects with simple and clear object lifetimes. However, that doesn't mean that the smart pointers are somehow overwrought for the job -- programmers have a tendency to distrust code they didn't write themselves, but its always more dangerous to roll your own.
I also suspect that you underestimate how truly wary one must be in the face of exceptions (as just one example) -- its not enough to simply have matching pairs of new and delete in the constructor and destructor -- that, alone, will (not might) leak. To be leak-free in the face of exceptions, you need to be completely aware of the exact state of the partially-constructed objects at all points during construction and destruction, including inherited-from objects. Then, you need to be sure that some other programmer isn't going to come in behind you and move or introduce statements in your carefully-ordered code, which could break its ability to deal with exceptions correctly.
Just use the smart pointers, and all of this worry goes away so you can stop wrestling details and get on to code you care about.