Like, in the world where I've referenced this in 3 of my 4 previous comments, as an example of a serious application built without RAII, which leans heavily into arenas, resulting in extremely compact and fast code?

You bringing up something unrelated doesn't mean anything just because you keep bringing it up.

Do you think anyone thought that nothing can be built without RAII? Did you think that was an argument anyone was making? Do you think someone walking barefoot means shoes don't do anything?

Is this an exam?

There is one singular question and you seem to think it's absurd to answer it and not veer off into a hundred different directions about unrelated projects and your favorite influencers instead of being able to focus on it.

it's that RAII comes at a large cost in terms of typing

If it automates things why would it have a typing cost? That makes zero sense.

it will "infect" your codebase,

How? It can be used or not.

requiring an all or nothing approach or you're actually back to manually managing memory

It's completely the opposite, you can use data structures that have destructors or not use them at all, this is not only not true it doesn't even confront the utility.

It will break modularization of your codebase, leading to subtle but substantive degradation.

These are strange claims, they don't have any evidence because you didn't explain why this would be true. It nonsensical, have you ever actually used these features? What does "substantive degredation" even mean or refer to? It's just running deallocation automatically, which you already have to do.

This is part of what leads to long compile times

No it isn't, it's running the same function at the end of a scope. Where are you getting this idea? Templates you could say this about, but a simple concept has nothing to do with it.

RAII adds temporal coupling between memory allocation and data lifetimes,

"Temporal coupling" doesn't make any sense, you have to deallocate memory anyway, why would it be any different to not have to write the line explicitly?

Separate allocation approaches on the other hand allow for better modularization and abstraction, and allow to handle allocation more centrally instead of cluttering allocation conerns across all types of a codebase.

Why would this make any sense? If you want to create a global you create a global. If you aren't freeing something when you don't use it, you're creating a global whether you want to or not.

This whole thing reads like being at the end of a game of telephone, there are no actual explanations in here and pretty much nothing that makes sense, but at least you actually focused on the question.

If you want to have a real explanation, especially to yourself, you should probably show a scenario on godbolt or something like that. It really seems like people have led you down a path that doesn't make sense and you haven't gone back and tested it yourself.