In my experience, a lot of programs aren't good at waiting for something that was expected to be nearly instant.
As far as I can tell, the program sends a request for data, and then repeatedly and rapidly requests if the data has arrived.
It's the equivalent of the parent to child conversation in a car:-
Child: "When do we get to the seaside?"
Parent: "Soon."
Child: "Are we there yet?"
Child: "Are we there yet?"
Child: "Are we there yet?"
Child: "Are we there yet?"
Child: "Are we there yet?"
etc.
It probably takes more effort on the part of the programmer to reduce the frequency of requests if the data is slow arriving, and that would risk making the program slower when the data arrives nearly instantly. It is likely that the programmer was writing the program and testing in a situation where the data was available nearly instantly, so the problems triggered by slow data are not seen and fixed.
Where the program's main function is to send and receive data, and the program is more mature, it's clear that some effort has gone into making the program work better in situations where data is slow. Moving and downloading files using file explorer seems not to cause the computer to work very hard, and a useful progress indicator is shown to the user. Similarly, the video streaming services have ways of indicating that the initial buffering is happening, and some will start videos at low quality, and then increase quality when it's clear that higher data rates are available.
Those improvements have taken a lot of programming to get to work seamlessly. Programs that mainly run within a PC, but just need occasional data from elsewhere may not have that sophistication.