Just to be clear
The WriteFile UM API accepts a single buffer consisting of continuous virtual address space. If the size of that buffer exceeds 1 page, it is very likely that the physical memory that backs those virtual addresses will be spread around the physical address space. Part of the ordinary job of drivers is to describe those discontinuous physical addresses to devices in a way that the device can understand. The device always has to work with bus local addresses. If it can perform DMA only one ‘block’ at a time, then that is how it must be done, but devices that can consume data from multiple discontinuous physical addresses together can ‘gather’ it as part of a single DMA.
The WriteFileGather UM API accepts an array of buffers in virtual address space. Each of these buffers is at least 1 page in size and are always even multiples of the page size. These buffers represent logically continuous data that is not continuous in UM virtual address space and may be even more fragmented in physical memory. In simple terms, the job that the driver has to do with this set of buffers is no different than the job it has to do with the ordinary WriteFile buffer.
Obviously I am skipping many details, but the point is that you cannot control driver behaviour by choosing one API over the other. Both APIs need scatter / gather DMA if sufficiently large IRPs are sent and the hardware will support it. The scatter / gather APIs are useful only when there is a specific layout of memory in UM virtual address space and you want to get it to or from KM faster. And on modern hardware, the ‘faster’ is very slightly faster if at all unless there are very specific conditions