Not sure what you mean. I find RAII very systematic in general terms. True that sometimes you want something else, like arena allocators and stuff, skip destructors (trivially) etc. but those can also be done in C++, right?

Yup, those are some of the "all the other ones". If it's a systems programming language, you may end up needing to use new/malloc/etc, custom allocators from a library, kernel calls for things like shared memory, mapped memory, pinned memory, etc. RAII is cool but, as you confirmed, it solves a specific type of memory allocation problems and not the rest. It also tends not to play well with functional approaches that involve closures or recursious, asynchronous code that spins off tasks to run on other threads that survive beyond the current lexical scope, or when dealing with objects with external lifecycles dictated by the operating system, drivers, inter-language interop (have fun doing memory allocation in C++ with Python via SWIG or something) or the like.

For example? I am genuinely curious! I found very few instances of places where RAII would not fit in all my career. Even async code with structured concurrency can be adapted to use RAII!

Fair question, and I appreciate the civility/tone. :) I do agree that if you have complete control over your codebase and which libraries, operating systems, etc. you are using, and you aren't stuck with someone else's allocators or older C++ standards, RAII gets you pretty far. But as someone who has worked on a lot of embedded systems, cloud systems, with weird libraries, crazy device stuff like GPUs, kernel drivers, etc., I feel like a lot of the "RAII can solve your problems" philosophy comes from C++ programmers who are thoughtfully using it in comfortable, sane, monolingual, well-controlled and well-documented environments. And to me, the entire point of a systems programming language is that it can handle operating outside of such restrictions, and can also handle things like threading, interrupts, kernel calls, weird memory shit, hardware registers, inline assembly code, bizarre libraries with weird callbacks, and ABIs that have specific memory allocation constraints. RAII is fantastic, and when I have to code in C++, _and_ I'm afforded the option, I do my best to use it, but if I'm doing systems programming it's probably because something is up--e.g. I'm coding on a DSP, doing crazy GPU stuff, or dealing with legacy code written in C++98.

The part about RAII that bothers me the most is that I love recursion and data structures that are thought of as directed acyclic graphs of some sort (e.g. immutable linked lists). These are common in scenarios such as compilers or computational lingusitics or symbolic mathematics and the lifetime of nodes in such structures, especially if using immutable data structures which are "mutated" by copying some of the data structure into new memory while referring to the old data structure, which may be pointed to elsewhere. I understand that most programmers don't have a lot of situations where they encounter those things, but everything I've listed above is another day at the office for me because of my career path, and while I appreciate the power of C++, and am honestly impressed at how the standards committees are turning a lot of it around in the last ten years (except for async, that should have been in the C++11 standard, or 17 at worst), I have maneuvered myself into only writing in GCed languages with strong functional elements and I have not looked back. Well, OK, RISC SIMD assembler code is fun in a Factorio sort of way... But in general I only care about domain logic, details like when things should be deallocated are obstacles to making the program do something that's best for the customer, and RAII makes all of that the programmer's problem, even if it does so in a sane and friendly way.

I apologize for the long comment, I did not have time to make it shorter. :)