The documentation for CreateMutex, in the description of the lpSecurityAttributes parameter, links to Synchronization Object Security and Access Rights which happens to explicitly confirm:
The handles returned by CreateEvent, CreateMutex, CreateSemaphore, and CreateWaitableTimer have full access to the new object.
Meaning even if you had passed an explicit SECURITY_ATTRIBUTES which would have ultimately denied yourself access to the created object, you're still granted full access on the handle returned from the creation API.
Is the same true for the Nt/Zw/Io/CreateFile API family when a new file gets created?
Not just the case of having provided an explicit SECURITY_ATTRIBUTES, but even the case of passing NULL to get the default inherited DACL. Where although the parent folder permissions clearly must have allowed you to create a new file, ultimately the inherited permissions which will be applied to the created file will not permit the requested DesiredAccess to the file.
Is there a clear and acknowledged exception for "the creator of this object will obtain a handle with full access granted" when it comes to the file system?
For example, when the same caller closes the handle received from creation, and then tries to re-open the now-created file with the same DesiredAccess, they will and should receive STATUS_ACCESS_DENIED due to the DACL applied during the file's creation. But they did not receive STATUS_ACCESS_DENIED during creation of that file, even though the same DesiredAccess was requested.