log why the permission is denied

routine, or are you listing this as an advantage? In any case it's far easier with logs than with the other options being listed.

> access permissions

configurable by the sysadmin

> information leakage

configurable by the sysadmin, just like all other information in the logs. This is even ignoring the syscall to disable it that was mentioned

> file formats

Yes, this is a wonderful advantage, the data can be put in whatever file format the sysadmin wants.

> high cost of error path allowing denial of service.

Only if you configure it to be a denial of service, Again, this is up to the sysadmin, some admins may want to run a system so locked down that if the log cannot be written they want the system to stop. Most admins won't want this, and this behavior is configurable in the logging daemons.

everything you mention is either a solved problem, or a strong advantage of having this information in logs rather than in some temporary memory structure that requires that applications be modified to gather the information (and in almost every case, that gathered information ends up in the logs from the application)

Logs already contain sensitive information, in fact, any substantial body of logs is going to contain user passwords, from the simple fact that it's valuable to track failed login attempts and _someone_ will get out of sync with the software and type their password in the userid field, followed pretty quickly afterwords with a successful login by that same user.

This is part of the reason that system logs (at least authentication related logs) need to have their access restricted to the admins. I don't see any reason that this extra information about denied access would be any different.

And I flatly reject the concept that the reason for denying access needs to be kept secret from the sysadmin who's running the box (who may need to grant the access)