That's certainly a thought and your point about the GIL is also a good point. If the streaming of gcode is happening in the main thread of Python and some GIL treachery is occurring then pushing that to another thread would help things one could guess.
And yet, people with Repetier also indicate issues with blobbing.
"My works-for-me solution was to change the movement buffer to 64. I'm using Repetier and anet A8, so plenty of free ram because of the microcontroller used: ATmega1284P.
The default value is 16, which it's small for very tiny segments (circles), 32 should work too If not enough ram available."
It feels like we're actually discussing Marlin-with-streaming and Marlin-from-the-SD-card. Any streamed software pushing to Marlin is apt to see this, I'd wager.
"The ASCII buffer for serial input. Individual command line length is set by MAX_CMD_SIZE, and should be long enough to hold a complete G-code line. Set the number of lines with BUFSIZE."
~ Marlin firmware docs
So we're talking about number of lines in that buffer, not 4K or anything like this. Honestly, four frickin' lines is crazy considering the veritable 115200 fire hose that is serial communications these days.
It feels to me like the Marlin crew set defaults that are good for the lowest-common-denominator instead of setting them for the least pain out-of-the-box. Being on the support end of this, I don't love that stance.
Here's my guidance on blobbing and Marlin tweaks.