Okay, well I kind of lied.
Using Bome for loopback MIDI can introduce a form of buffering. It depends on how both Bome and the host are implemented, and I haven't measured it. But in theory what can happen is this:
LIke I mentioned in a different post, both Mobius and the host are driven by the audio interface asking for a constant stream of audio blocks. I call this the block processing cycle. Every few milliseconds, the audio device asks for a block and the host fills it. What the host fills it with may come from several sources. The host itself may have tracks of audio that are playing. The host also asks any audio generating plugins for their blocks, and merges it. Finally if the host has virtual instruments, it looks to see if any of those were playing or were just now triggered by a MIDI event. If so, it takes the output of the virtual instrument and puts that in the block. When it is done gathering up all the contributions, it then passes the block to the audio interface. It then waits for the audio interface to request the next block, and this cycle continues forever.
When MIDI is involved, it doesn't enter the host in the same way that audio does. MIDI effectively has it's own "channel" that is independent of the audio stream. How MIDI events get interleaved with audio blocks depends on how the host is designed, but often, and this is certainly how Mobius does it, any MIDI events that are received get queued and processed with the next audio block. So there may be a few milliseconds of delay between the time a MIDI event is received, and when it is acted upon. If the MIDI is being used to trigger commands, it may take action immediately, but if it is doing something that causes audio to be generated, this has to be delayed until the audio interface asks for the next block.
As an example, let's assume there is an extreme audio block size that causes a full one second of latency. Once a second, the interface asks for a block, the host fills it, and this process repeats. In the middle of that 1 second, a MIDI event comes in that is supposed to trigger a drum hit. A drum hit is just a short sample that needs to get injected into the audio blocks. But the host can't do that right away, it already gave the audio interface a 1 second block, and it has to wait for the interface to fully consume that block before it can give it another one. So in effect, the sound of that drum hit isn't going to be heard until 1/2 second after the MIDI event came in.
So the block processing cycle typically has these steps:
1 Did any MIDI events come in since the last block? If so inject any samples that were triggered by that event
2) Do I have any tracks playing? If so inject whatever the tracks are playing
3) Are there any plugins? If so, get an audio block from them
4) Did any of those plugins generate MIDI events to be sent out? If so, send those to the MIDI device
When Mobius generates MIDI that is being sent to Bome, and looping back into the host, steps 1 and 4
are important. If the host does its incoming MIDI processing first, then even if a plugin generated MIDI in step 4, the most may not do anything with that until the next block. The host thinks it is done with MIDI for this cycle, and the fact that the plugin caused something to be sent back to it won't be detected until the next cycle.
If instead you did not use Bome, but sent MIDI out through the normal plugin MIDI ports the host might see that take action on it during the current block cycle, rather than waiting for the next one.
As for how FL Studio specifically behaves, I don't know. Maybe it is smart enough to check for incoming MIDI several times during the block cycle, but I doubt it. In that extreme 1 second example, the host isn't sitting around for that entire second to see if it needs to respond to anything new that comes in before it hands the block off to the audio interface. It's going to do what it does as quickly as possible, so if Bome adds even a few microseconds of delay that may be enough to push it into the next block.
In general then, if you want a Mobius MIDI track to be sending events to a virtual instrument in the host, it is probably better if you can arrange to do that with host routing rather than using loopback MIDI. That way, the host can see how the entire process is going to play out, and take a multi-phased approach to assembling that audio block.
Whether you can even notice any of this though depends on a number of things. If the block size is small, 128 or less, most people can't hear that. If the attack envelope on that drum sample has some slope on it, that makes it even harder to detect.