Metal Best Practices Guide states that
The setVertexBytes:length:atIndex: method is the best option for binding a very small amount (less than 4 KB) of dynamic buffer data to a vertex function
I believe this means that instead storing uniforms in an overly complicated manually memory managed dynamic buffer, it's best to simply update model/view/projection matrices without using any buffer at all, by using setVertexBytes and setFragmentBytes.
My question is, that in this case, as there is no dynamic buffer at all (only static vertex data), what are we calling triple buffering?
Is it simply because we have a semaphore with value: 3 left now?
If you are using setVertexBytes and its ilk instead of explicitly using buffers to pass in dynamic data, I would agree that you're not "triple-buffering" in any real sense. In fact, you could omit the semaphore, since at that point, there is no resource to which you're guarding concurrent access.
You may (but probably won't) still block waiting on a drawable to become available, but that's a limitation of the presentation architecture, and a separate concern from whatever buffer management you might or might not be doing.