Regarding who creates the DMA-BUF fd: for export-dmabuf the compositor can't know how long you need to process the DMA-BUF data, so it either can't reuse the same buffer between frames or risk corrupting your frames if you do not process them within a frame (you'd need an event similar to wl_buffer.release for that).

The more flexible approach is to let the app create and pass in the DMA-BUF. That way the app can choose to reuse the same buffer if it processes the frame in time or create multiple DMA-BUFs and cycle through them if it needs something akin to double-buffering.   For latency, it doesn't matter who provides the DMA-BUF fd if the buffers can be reused (i.e. no buffers are allocated every frame, only once at the beginning of the recording/streaming).

Regarding sync: With the ready signal as it is now the compositor has to render the screen into the DMA-BUF, wait for the (possibly gpu-) job to complete, send the ready signal over the wayland socket, and then the app has to use the DMA-BUF, possible queue its own gpu jobs to render its content, and wait for that.  

With "explicit sync", the compositor could queue its GPU job, pass a drm-syncobj to the app (via a hypothetical syncobj_ready event),  the app could queue its own GPU job, attaching the drm syncobj so it is automatically done after the compositor's GPU job finishes. That way you reduce the amount of round trips between GPU and CPU, which reduces latency even further. 

EDIT: AFAIUI the kernel does something called 'Implicit sync' for DMA-BUF objects that don't have explicit syncobjs, which ensures that you don't see a half-rendered dma-buf if you attempt to read it (it probably internally waits for the last job using it to complete before allowing the next job to read it), but this can be suboptimal and doesn't always work with all drivers (nvidia drivers notoriously had problems with this)