During my own internal testing I found that any ACEs with types ACCESS_ALLOWED_CALLBACK_OBJECT_ACE and ACCESS_DENIED_CALLBACK_OBJECT_ACE does not count during access control processing. I made different variations of the ACEs: with or without ObjectType GUID, with or without ApplicationData field, with ApplicationData having correct "conditional expression" (as described in [MS-DTYP] 2.4.4.17). In all cases such ACEs had no influence on access checking process. At the same time I was able correctly apply any ACCESS_ALLOWED_OBJECT_ACE and ACCESS_DENIED_OBJECT_ACE. Also I am able to build correct ACEs with types ACCESS_ALLOWED_CALLBACK_ACE and ACCESS_DENIED_CALLBACK_ACE.
So, seems like internally in a callback function like "AuthzAccessCheckCallback" for ACCESS_ALLOWED_CALLBACK_OBJECT_ACE and ACCESS_DENIED_CALLBACK_OBJECT_ACE I got "*pbAceApplicable = FALSE".
Additional details: I am making all the security descriptors using my own library on C++, access checking performed by "AccessCheckByTypeResultListAndAuditAlarmByHandle" function. All was tested on Windows 10 under a process having elevated administrator account (with all related privileges enabled). Plus I tested the same code on fresh installation of Windows Server 2019 having configured ActiveDirectory domain - same result, such ACE types does not count during access control checking.