I don’t see how. On the receiving end you still have to handle a note like a note, so every midi message, status byte or not, has to be identified and handled accordingly.
Maybe you can save a couple cycles on a microcontroller when sending, but I doubt it.
Like I said, the savings are mostly relevant on a DIN connection.
It is true that a lot of devices support it on the receiving end because it’s part of the midi spec, but there are barely any devices that use this for sending midi.
If you test all your keyboards, controllers and sequencers, you’ll probably find that none of them uses it.
It is used in midi file storage, because it saves storage space which was very expensive in the early days of midi.
The only modern midi connection that supports running status is BlueTooth LE MIDI.
If you’re using USB MIDI, every midi message that doesn’t have a status byte will get one before sending, negating all your efforts.
So, unless your code is for a device that receives midi over DIN or BLE, I wouldn’t bother.
But in those 2 cases, the midi spec dictates that you implement it.
It’s the only reason why
(NOTE_ON, velocity 0) == NOTE_OFF.
If you want a place to save bandwidth, look at NRPN messages. These are implemented with their own form of running status which saves 50% of the bandwidth and actually works with USB MIDI.
However, keep in mind that this will fail when merging.
NRPN can also be supplemented with a null function message, but that will cost bandwidth, not save it.