Yes, because USB MIDI Event Packets are not allowed to contain a running status message. If you tried, the message would be ignored or cause an error.
Cheap ones can’t. But besides that, you’re talking about a converter.
A converter will add a status byte to every message when converting from DIN MIDI to USB MIDI, before it ever hits the USB controller.
When converting USB MIDI to DIN MIDI, messages will always contain a status byte unless the converter implements it’s own running status.
But from the USB side, you simply cannot send or receive a running status message.
It’s not just a transport protocol for the same MIDI data because running status would get lost on conversion.
There is no such thing as a “running status message”.
When a Status byte is received and processed, the MIDI receiver will remain in that status until a different Status byte is received. Therefore, if the same Status byte would be repeated, it can optionally be omitted so that only the Data bytes need to be sent. Thus, with Running Status, a complete message can consist of only Data bytes.
The USB-MIDI converter provides the link between host and USB-MIDI function and is basically a software driver so I don’t understand when you say “cheap ones”.
The USB-MIDI protocol does not take advantage of Running Status because event packets are always 32 Bits long. So even a single byte of MIDI data would be sent as a 32 Bit package and the unused bytes are padded with zeros. USB speed and bandwidth are such that it simply does not need to reduce MIDI data.
If MIDI data is received over DIN, and is then forwarded on over USB, one of the functions of the converter is to the transfer the MIDI events, parsed into 32 bit messages for standardized transfer over the USB and for easy handling by MIDI devices. The MIDI data itself is transferred transparently, without any changes.
If MIDI data is received over USB, and is then to be forwarded on over DIN, the data is re-packed and there is no reason why Running Status cannot be employed because it is simply the omission of unnecessary Status Bytes.
Which is what I mean by a running status message, a message sent using running status that doesn’t have a status byte. It’s just semantics.
Cheaply made USB to 2 DIN plugs converter cables. Those often have problems converting DIN to USB when running status is used.
According to the USB MIDI spec, there is no Code Index Number for Note on or Control Change messages that are only 2 bytes long.
That’s what I mean when I say it’s not allowed.
The Status Byte is expected, so it has to be put in when parsing to a 32bit USB MIDI Event Package, which means any use of running status gets lost before transfer.
There is a special case if you want to send unparsed midi data, but that would mean using the whole 32 bits for a single midi byte for no good reason.
I agree, all I’m saying is the way you format your midi data on the USB side has no influence on this. Running status has to be implemented after reception of the USB packet.
OK we are obviously both aware of the relevant specification. 
I think your assumption is that when data only messages are converted to USB-MIDI a status byte is added.
My assumption is that when data only messages are converted to USB-MIDI a status byte is not necessarily added.
Unfortunately reading the spec does not absolutely clarify what actually happens as Running Status is simply is not mentioned.
The spec does say “The first byte in each 32-bit USB-MIDI Event Packet is a Packet Header contains a Cable Number (4 bits) followed by a Code Index Number (4 bits). The remaining three bytes contain the actual MIDI event.”
I think that if the actual MIDI event only contains data bytes that is all that will be used.
Die hard nerd talk going on here 
I think if you would implement it this way, it could work just fine for midi reception.
You could just assume running status and handle it that way.
But there is one little sentence in the spec that makes me think you can’t get away with this for sending midi, thus also making it invalid for reception.
On page 16 above the index table:
The Code Index Number(CIN) indicates the classification of the bytes in the MIDI_x fields
The Code Index Number for i.e.: Note on states 3 bytes.
If each of those bytes has a set classification, missing the Status Byte and padding with zeroes would mess up the order, making it an invalid message.
I think that’s why Running Status isn’t mentioned once in the whole document, it doesn’t exist in USB MIDI. The documentation could be a bit more clear about this though.
The spec does indeed show 3 bytes for the “Note-on MIDI-x Size” but that could indicate the maximum byte requirement of a Note-On message? The spec also states “The MIDI data itself is transferred transparently, without any changes.” Adding status bytes could be viewed as altering the original MIDI data?
Playing and releasing a 4 note chord generates 8 MIDI messages which could be transmitted as 3 bytes for the first message and 2 bytes for each of the subsequent 7 messages. Generating a status byte for 7 messages seems a bit inefficient?
As you say this a quite a nerdy in the weeds discussion and I suspect what actually happens is difficult to determine and is certainly not something that actually matters or will make a difference either way. 
I see it more as “running status ceases to exist” as soon as a MIDI stream hits a USB connection.
The connection is still transparent because no data is lost, in fact, you get some reconstructed data for free. 
At first, you would think that.
Until you look at the handling of sysex in the example.
There are actually 3 different Code Index Numbers for a sysex message that ends with 1, 2 or 3 bytes.
If padding with zeroes was automatically recognised, this wouldn’t be necessary given that the 'end of sysex', 0xF7 is also present in the event packet.
It seems that way, until you realize you need a Status Byte anyway for setting the Code Index Number.
And if you’re converting from DIN to USB, you’re already keeping track of the last Status Byte in case the device on the input uses running status.
If it was actually efficiently implemented, you would be able to send those 8 midi messages with running status in 6 packets instead of 8.
What seems more inefficient to me is that in most cases, the first 4 bits of the Status Byte sits twice inside the 32 bit Event Packet.
Or why do we even need Code Index Numbers? MIDI DIN works fine without them right?
I think it comes down to some internal logic in the way USB controllers work, and most processors calculate with 32 bits minimum so there’s a connection there.
Transmitting MIDI this way also seems less prone to errors, since you know exactly what information will be in which place, so no extra interpretation of the data is needed.
Oof, sorry for the long and post.