USBOpen(), USBSend() and USBRecv()

[gehakte_bits]

The USBOpen returning ({64,64}) tells you the block size the FT260 USB-HID device will do. So the Prime will receive 64 bytes at once. The USB HID interface speed is 64Kbyte/s, so 64 bytes (1 block) per 1 msec.

Since you are sending serial data at 19200 N,8,1, it takes 33 ms to fill that block of 64 bytes. One can wait until the block is filled, introducing a lot of latency (when/how long do you wait for small packet frames << 64 bytes?) or send the data as fast as possible (at 19200 N,8,1 about 1~2 bytes every 1 msec, you see that in your steady state).
(Ignoring things like OS delays, USB suspend-wake delays)

The HID device is not going to wait, in order to reduce latency for its interfaces, and to hide the knowledge of the end-of-data for each and every possible application, leaving it up to the receiver to re-assemble the user data, based on opcode and/or packet length. So 'the way' is to have fun coding the re-assembly of the received packets (or break up data you send...) at the application layers.

If you have a faster interface (i.e. I2C) you see it fills the full 64 bytes:
((wr) request (0xc2) to I2C-device (0x50) read (0x06) 256 bytes (0x0100)
((RD) read opcode (0xde/0xd3), size (4 * 0x3c + 0x10), actual data cropped...)

wr C2 50 06 00 01 00 00 00 00
RD DE 3C 08 30 60 00 00 A0 40
RD DE 3C 00 30 00 10 03 46 00
RD DE 3C 00 00 00 00 00 00 00
RD DE 3C 00 00 00 00 00 00 00
RD D3 10 00 00 00 00 00 00 00