The sort order of physical devices returned from vkEnumeratePhysicalDevices() is undefined (without explicitly added instance layers like vk_layer_mesa_device_select). It is inconsistent in practice and differs between different Wine processes (e. g., based on some random factors I get different order on a dual AMD GPU laptop).
For add_gpu() (in win32u/sysparams.c) the order is important. The incoming GPU order defines gpu->index which is a part of GPU registry path. So when identical GPUs are enumerated in driver in a different order that is effectively results as deleting both GPUs and creating new ones, leading to various inconsistence, e. g. (but not limited to), just setting display mode may be lost and reset to default during enumeration with forced GPU requery from driver. This is addressed by the first patch. In theory this part can maybe be addressed another way, by explicitly setting device index in some other way, but that looks much more complicated with unclear benefits.
Then, when Vulkan devices are not associated with Vulkan GPUs (happens whenever xrandr is essentially broken, always the case on Xwayland), add_gpu() depends on the consistent order in its own Vulkan GPU enumeration (addressed by the second patch). Since this path is essentially a workaround which relies solely on Vulkan devices sort order to be reproducible between enumerations and consistent between processes it looks like sorting is the only way.
WRT this particular problem sorting could be done without introducing ordering by GPU type (discrete / integrated / software) only using UUID but it looks better to me to have that as an explicit part of the sort. In particular, software devices happen to go to the end of the list on Linux and Windows, making them accidentally go first may confuse apps.