> That web page does not claim that anywhere.

Here's a rough list of the DT changes performed by the firmware, besides merging the obvious dtoverlays and dtparams:
* Applying the "upstream" overlay, if "upstream_kernel=1".
* Changing the CPU ID declarations on a Pi 2+ (BCM2837 vs BCM2836).
* Adding i2c_vc and i2c_arm labels and aliases (and their relatives).
* If the board has a POWER_LOW GPIO declared in dt-blob.bin, using that to configure the pwr_led node.
* Adding the Bluetooth flow control pins to the "uart0_pins" node, on boards that support it.
* Setting numerous items to /chosen - bootargs (the command line), rpi-boardrev-ext, rpi-country-code (Pi 400), details of the bootloader version, boot-mode, linux,initrd-start and linux,initrd-end.
* Adding a copy of the bootloader configuration.
* Loading the vl805 overlay on CM4s which have "VL805=1" in their bootloader configuration.
* Automatically loading overlays for supported cameras that are detected.
* Automatically loading overlays for the PoE HATs, switching between firmware-driven and I2C-driven as needed.
* Expanding the dma-ranges property of the emmc2bus node on BCM2711C0.
* Disabling the old OTG USB controller and enabling the XHCI controller if "otg_mode=1".
* Loading the appropriate rpi- display overlay.
* Setting the aliases "serial0" and "serial1" to point to the console/user UART and the Bluetooth/spare UART, respectively.
* Adding information about the HAT in "/hat".
* Copying any significant error messages to "/chosen/user-warning", from where it can be read by the GUI and turned into notifications.
* Declaring the available RAM.
* Passing the board revision, serial number, kaslr seed and rng seed.
* Limiting the size of the CMA region to 256MB if < 2GB RAM or gpu_mem > 256.
* Expanding the inbound window declared by the pcie0 dma-ranges property on a C0, moving the base address to 0x4_00000000 regardless.
* Setting the MDIO address of the Ethernet PHY.
* Declaring a simple-framebuffer, if wanted.

> What does m1n1 have to do with anything here? m1n1 isn't extlinux and isn't packaged in Guix.

It chainloads uboot

> Going by the mention of 'defconfig' and 'arch/arm' and 'configs', this appears to be a patch to Linux, not uboot. As such, it appears that the device tree information is used by Linux here, there is no information there on whether it is used by U-Boot.

I cannot agree.
https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-bcm283x/Kconfig <https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-bcm283x/Kconfig>
https://github.com/u-boot/u-boot/blob/master/configs/A10-OLinuXino-Lime_defconfig <https://github.com/u-boot/u-boot/blob/master/configs/A10-OLinuXino-Lime_defconfig>

> And is this a bad thing, and if so, perhaps FDTDIR could be added to the specification?

I don’t think so. Keep in mind the source code in Guix is named extlinux.scm and the file is named extlinux.conf and extlinux doesn’t support FDTDIR

> If so, figuring out the appropriate options to let U-boot pass the device tree to Linux seems reasonable to me.

Of course it passes device tree. The problem in question is the source of that device tree: in my case, it should not be loaded from a file.