However, the ZeroMQ author goes a lot further than that for his specific application.
He made some reasonable arguments that even the use of OOP/classes in C++ makes catching undefined behaviour unnecessarily difficult for systems programming.
Similarly one can imagine using RIAA to hold a file lock, or a temporary directory; this is a perfectly reasonable thing to do but there are dozens of reasons why the final rm -rf of the tempdir could fail.
The idea that somehow object teardown is immune to failure is overly naive, and the fact that you can't accommodate it easily in RIAA is quite disappointing and makes the whole paradigm much less useful for carefully coded software.
For example, fclose can fail, but even if it does, the stream given is no longer held. In fact, any further use of the stream is undefined. There is certainly a place for logging in this situation, but if close was a behavior of the class, it should have a separate close function.
As far as locking goes, it is the responsibility of the locking routine (probably a semaphore) to release the callers hold on the lock, but it is not the callers responsibility to ensure that whatever resources are associated with the lock (e.g., a file) actually get deleted. That is the locking object's responsibility.
I agree that some aspects of RAII could be better, but C is not the answer to that. C doesn't even have scope-based RAII.