Why wouldn't GRUB be able to handle this?  Loading a device-tree like this is simply loading a file and placing it at an appropriate address address in an appropriate structure in memory.

The setup I've described is accomplishing this in two pieces.  "flash-kernel" copies the kernel device-tree into /boot/dtb-${kernel}.  The GRUB patch modifies /etc/grub.d/10_linux which in turn adds lines to the resultant grub.cfg file, the crucial line is "devicetree /boot/dtb-${kernel}" (where ${kernel} is the kernel version string).

I've been given the impression GRUB's "devicetree" command exists in 2.02.  Yet without the linked to patch (or an equivalent) the invocation of "devicetree" doesn't appear in grub.cfg and the device-tree never gets loaded.

This edit came in after I was already typing.  What do you mean?

Unfortunately the functionality is usually provided by the `flash-kernel` package, but if `flash-kernel` is installed it will copy the appropriate DTB from /usr/lib/<kernel-version> to /boot/dtb-<kernel-version>.  The GRUB wishlist bug 52939 includes a patch for /etc/grub.d/10_linux to cause GRUB to load the device-tree from /boot/dtb-<kernel-version>.  The patch was made for an older version of GRUB thus needs manual application and also needs to modify /etc/grub.d/10_linux_xen.

Numerous people have demonstrated it isn't much work, and has distinct benefits.  Most of the work is getting people claiming it is too much work to get out of the way.

I think you just demonstrated why I'm highly underwhelmed by device-trees.  Their implementation is awful.

No, it isn't.  I'm far from expert in these pieces, but I've gotten things functioning without much work.  A very little bit of scripting might be needed, the main work is keeping the pieces synchronized.  Mostly needing to keep a combination of U-Boot, GRUB and device-tree which are compatible together.

Have I mentioned device-trees are garbage?  (this could merely be an issue of lack of standards, whereas UEFI was an organization behind it keeping things mostly sane)

That doesn't seem easier except for the first time setup.  Maintenance is harder since it means spinning everything by hand, whereas GRUB has everything scripted out of the box.

More importantly, you missed the second part.  I don't believe extlinux can load Xen (two kernels plus an initial ramdisk).

You use U-Boot's UEFI support to have it load GRUB (SuSE uses this approach).  While wasteful due to having an extra bootloader stage, you gain GRUB's massively better functionality.

There are at least two massive improvements.

U-Boot can boot one kernel.  Just one.  There are no backups, fallbacks or any flavor of Plan B.  If you try to build a modified kernel with even the slightest modification, U-Boot can be adjusted to boot that kernel and only that kernel.  With devices in the embedded space having grown rather larger, customized kernels are no longer such a big deal, but I for one still rather like having easier recovery options.  GRUB provides this by allowing you to select from multiple installed kernels.  U-Boot and GRUB do get updates, but those are generally once every few years (distribution release/update) rather than every few months (Linux kernel security updates).

GRUB is also rather more functional for interesting setups.  Notably GRUB's scripts are readily setup for booting interesting options.  By interesting what I mean is GRUB can boot FreeBSD or Xen.  Devices with hardware capable of running Xen are becoming more common (Raspberry PI 4B), so allowing for booting such setups out of the box is a Good Thing.

I note SuSE has chosen the route of U-Boot => GRUB => Linux kernel, so Devuan would not be alone if this approach was choosen.  It is also noteworthy EBBR requires UEFI support so the next/current generation is converging on an interface suitable for GRUB as the common point, not U-Boot.