I think I understand what is occurring here. Unfortunately, I don’t have a good solution right now.
What I think is occurring is that the homing speed is resonating with the TMC UART transmission speed on AVR micro-controllers.
On this delta printer a homing speed of 35mm/s results in 2800 steps/s (a step every ~357us). Because of the way deltas work, every step is actually three steps (one for each tower) scheduled at the same time. Similarly, there are 2800 endstop checks per second (and again, the three endstop checks are all scheduled at the same time). This means the (relatively slow) atmega2560 mcu has a lot of work to do on bursts that occur 2800 times per second.
On the atmega, the TMC UART code sends/reads a bit 9000 times per second (~111us). I fear some of the TMC bit transmissions sometimes get scheduled near the homing operation bursts, and that is resulting in scheduling jitter that corrupts the transmission. Although Klipper retries on a failure of this kind, it seems this issue could occur with sufficient frequency that sometimes even multiple back-to-back retransmits all fail.
If I’m correct, this issue is likely limited to AVR MCUs controlling delta printers (or printers with 3+ synchronized Z axes) using TMC UART drivers.
To test if theory is correct, you could try changing your homing speed to see if that makes the issue more or less likely to occur. I also suspect that issuing explicit SET_STEPPER_ENABLE commands will make the issue less likely (as that reduces the number of TMC transmissions that occur during homing).
-Kevin