After a few months playing with the Duet3 and SBC combination, I've decided to revert the duet3 back to standalone. The decision was made last night when my Raspberry Pi4 locked up. (It might have been a kernel panic. I don't know. The Pi was completely unresponsive until I disconnected power and reconnected to let it reboot.) This happened mid-print.
In the course of the last few months, I found that using the duet3 in SBC mode isn't limiting as I expected. While RRF 3.2.2 is slightly ahead of DSF in development, everything I needed worked properly or could be made to work with slight changes. Specifically, the PanelDue works fine when the Duet is in SBC mode, and any conditional g-code parsing issues I had with DSF were easily worked around. In other words, I found running with DSF to be stable and working.
However, there's no getting around the fact that the SBC is a multi-faceted additional point of failure. Not only can the Pi hardware can fail, but there's also the SPI ribbon cable, the additional power supply for the Pi, the OS running on the Pi, and the DSF software suite (This is in addition to all the things that can fail on a standalone Duet3 installation.)
At the current time, and for my particular installation, the only added value that the SBC offered to me was faster gcode upload speeds and an ethernet bridge. It also offered the ability to tinker that I never got around to taking advantage of. Even if I used a small touch screen with DWC on the SBC, I still think things would be more stable with the duet3 in standalone and the Pi running independently.
Perhaps one day RRF/DSFwill offer some advantage over standalone that will cause me to re-evaluate.