Thank you for your reply and good question!
1) stall is needed to create an incomplete USB transaction. You are right – this is necessary to prevent request completion, as a result of which you can create a request queue. The delay does not matter. Further requests can be executed even with a sufficiently long pause after the stall (for example, 10 seconds). In fact, the USB bus does not go into the STALL state (the STALL handshake packets are not sent, only NACK). At the same time, the controller is working in such a way that it always processes SETUP packets, which is why it is possible to create a request queue.
2) No additional requests are needed. As it turned out, in the presented version of the exploit, even a single stall request is enough – it will be overwritten with new "callback" and "next" values. Apparently, this is possible because before overflowing while executing the USB_REQ_SET_CONFIGURATION request (libusb1_no_error_ctrl_transfer(device, 0, 9, 0, 0, t8010_overwrite, 50)), another request will be created and it will remain in the heap (see SecureROM sources). It will play the role of a heap barrier and will prevent access to corrupted metadata of an overflowed request during further work with the heap. If you use a request from the original code (libusb1_no_error_ctrl_transfer(device, 0, 0, 0, 0, t8010_overwrite, 50)), then the second request is needed as a heap barrier.
libusb1_no_error_ctrl_transfer(device, 0, 9, 0, 0, t8010_overwrite, 50)
libusb1_no_error_ctrl_transfer(device, 0, 0, 0, 0, t8010_overwrite, 50)