It’s not really a matter of how much memory it allocates: the simple fact that it performs allocation means that it must call into the OS, which in turn means that the return time is not predictable.
For example, that allocation, however small, could be the last drop that causes the memory manager to decide to perform some reorganization, possibly swapping some memory to disk, which is very time consuming.
For sure that is what may happen on macOS, as also mentioned in the following post:
The bottom line is that on macOS the message queue is nothing but a reference counted array, also protected by a CriticalSection, which makes things worse from the realtime audio POV: if the audio thread tries to trigger the AsyncUpdater while the GUI thread is also posting a message, that will result in a contention for the CriticalSection that will make the audio thread wait until the lock is released by the UI thread