This approach starts getting brittle when you get into objects that aren't procedure-scoped; for instance, a global session table in a web application, or a request token tracker in an RPC system. These are also the kinds of object lifecycles that tend to be behind leaks and corruption in programs that don't use RAII.
People use shared pointers to mitigate that problem, but shared pointers are (a) a reference counting scheme with all the attendant problems and (b) not compatible with code that holds references but doesn't speak the same shared pointer scheme.
(It's been a bunch of years for me since I wrote C++ professionally; that may show here.)
I think the biggest fans of RAII are those who use it more academically -- in real life it is brittle and scopes are tricky. It is also just an idiom as compared to a compiler feature. And, IMHO, RAII tends to play poorly with others.
People use shared pointers to mitigate that problem, but shared pointers are (a) a reference counting scheme with all the attendant problems and (b) not compatible with code that holds references but doesn't speak the same shared pointer scheme.
(It's been a bunch of years for me since I wrote C++ professionally; that may show here.)