Note that each half of keyboard and module has a separate microcontroller. Somewhere in the blog they even showed a monstrosity consisting of one right half and 3 left halves connected together. In theory you could run qmk on the primary controller (someone will probably do that) but you would still need secondary firmware for all other parts. It might be more productive to add common import/export format for some of the keyboard layout creation tools than trying to share firmware.

Many sane assumptions made by qmk wouldn't apply to UHK which is possibly more complicated than a keyboard should be. Keyboard layouts in qmk are hard-coded in firmware and replaced by building a new firmware. That is a reasonable approach for 8-bit AVR MCU supported by qmk, not so much for UHK which has an order of magnitude more resources.

Maintaining all of that in single codebase might be more difficult to maintain for both UHK and qmk developers than doing it separately. Ifdefs all over the code would be a mess (there is not much room for abstractions using 2K of RAM). Testing if the functionality added by UHK developers doesn't break anything on 10-50 keyboards supported by qmk would also be a significant burden.