One reason for the long bootup time is the fact that Rigol is using an userdebug build. An user build (which doesn't offer e.g. adb root) boots much faster. I'd assume 5-20 seconds boot time reduction.
Agreed.
it sounds like the full sleep mode is complex because it relies on Rigol having wired it with independent power rails for logic & processing, and you'd have to reconfigure all the logic when coming out of standby (how long does that take?).
And, depending on how Rigol has implemented the FPGA, it might not even be possible (for an external team, at all).
Optimally, the FPGA itself would use standard PCIe power management, and the subsystems (analog frontends) one GPIO pin to control whether they're powered or not. (It may sound "obvious", but when the SoC GPIO pins operate at say 1.8V logic levels, it is not the most straightforward method; instead, a designer might opt for a power management IC, that only ensures everything is powered up in the right order, with no provision for sleep modes.)
GPIO support for RK3399 (and most common GPIO extenders like PCA954x) is baked in to the Linux/Android kernels, so it is just a matter of enabling the support in the kernel, and describing/exposing them in the Device Tree description.
If Rigol did it the PCIe ASPM + GPIO way, then various low power modes are possible with not too much effort (depending only on how complicated the power-up sequencing from sleep modes is).
Alternatively "PS Clock Control" can take the (FPGA) Arm processor from 766MHz to 30MHz which would save power in a standby mode, but I don't know if that would also underclock the power-hungry logic?
I wouldn't know; I haven't worked enough with FPGAs yet.
It is interesting to note that for Android 7 TV boxes based on the same SoC, like H96 MAX, typically use 5V 2A power supplies. Of course, the DHO800/900 also have a built-in display, and its backlight is likely to draw quite a lot of power, relatively speaking. I don't expect the front panel controls to draw much power at all (even the LED lights in them), so it really depends on whether reliable software control over the power hungry subsystems in the scope is possible or not. Often the turning off part is easy, and the turning on in the correct order, reliably, is the hard part.
(Which is also why I would not be surprised at all to find out that the Rigol DHO800/900 systems integration team were still working on exactly this. Having the system work reliably first, then concentrate on optimizations like bootup and power saving modes, would be the best approach, in my opinion.)