According to the first answer to this StackOverflow question, and the question itself, USB RS-232 serial ports can use the Abstract Control Model (currently specified in the Universal Serial Bus Communications Class Subclass Specification for PSTN Devices, Revision 1.2).
However, according to the second answer, at least some serial-to-USB chips have their own proprietary protocol.
See also this "Create a USB Virtual COM Port" article, which speaks of either using bridge chips that don't use the Abstract Control Model and require a vendor-specific driver or of using the Abstract Control Model implemented in a microcontroller.
Perhaps either 1) the USB devices do buffering differently or 2) don't even use the same protocol atop USB. The only way to "solve the issue for the RS422 so that the whole message would be as single frame" might be to replace the hardware used for the RS-422 line with hardware that uses the same mechanism as the RS-232 device. At least according to the documentation for this ATEN device, they do provide drivers, so they may be using their own proprietary mechanism rather than the Abstract Control Model.
(I.e., this may not be an issue with either Wireshark or USBPcap, it may be that, in fact, USBPcap is capturing, and Wireshark is reporting, exactly what's happening over USB, and it is, in fact, not being done in the same fashion for the two devices. USBPcap doesn't, and is not intended to, capture traffic the way you want to see it, it's intended to capture traffic as it appears on USB; similarly, Wireshark is intended to show what is captured.)