I'll try the Interrupt Service method. I did ask (Jan A. ) about the delays and she wrote back:

"Every API call adds overhead. An alternative would be to define an IN Feature report for each command and have the device send the response in the Data stage. That way you get the command and response in a single control transfer."

So I've been testing feature reports and now have 5msec response and faster depending on the PC, from the sample Feature Report given with the HIDMaker.
Next, if possible, I'll expand the End point sizes in the Feature Report and structure them for my application.

I just tested the timing with toggling pins:
I see 300uSecs between the last toggle of DO19 and the next toggle of DO20
and that was using INPUT and OUTPUT Reports.

ProgramStart:
gosub DoUSBIn 'Loops inside here until a command is received
GOSUB Handle_Cmd 'Command Executioner of the 'deed'
gosub DoUSBOut
TOGGLE DO20
goto ProgramStart

'================ USB SUBROUTINES =========

'************************************************* ********
' * receive data from the USB bus *
'************************************************* ********
DoUSBIn:
TOGGLE DO19
GOSUB Cycle_Leds
USBBufferCount = USBBufferSizeRX ' RX buffer size
USBService ' keep connection alive
USBIn 1, USBBuffer, USBBufferCount, DoUSBIn ' read data, if available
return
' ************************************************** *******
' * wait for USB interface to attach *
' ************************************************** *******
DoUSBOut:
GOSUB Cycle_Leds
USBBufferCount = USBBufferSizeTX ' TX buffer size
USBService ' keep connection alive
USBOut 1, USBBuffer, USBBufferCount, DoUSBOut ' if bus available,transmit
return

So next I'll use interrupts for the USB service calls for the INPUT OUTPUT Report code, then if it's still slow I'll expand on the Feature report code and use interrupts for the USBService calls.