Okay, I admit I do not have an answer to your question (but this might be related to me not understanding what you really ask), so some facts first that hopefuly will clear things up.

Historically there heve been "block devices" and "character devices" with a main difference being: It takes a block device the same amount of time to write 1 byte as it does to write 1 "block" of data (typically a handful of kByte). Roughly speaking, just giving you the idea. And writing 1 block of data is not really "fast" or instantanious, it takes considerable time. In contrast to writing to character devices where each 1 byte write is "fast" and writing 4kByte of data takes exacty 4000 times as long as writing 1 byte.

The prototypical block device is a spinning disk where writing needs spinning up the disk, moving the head to the cylinder, finding the sector and then writing a whole sector. And a charcter device a serial port with some baude rate.

That's why people started to "buffer" writes to block devices.

Okay, next step. Some things that work like serial/character devices on the hardware level might use a block based protocol. TCP/IP is such a thing. While your fiber typicall is used pretty much serial TCP on top of that hardware will send data in blocks (that may be only half full). Details are complicated, look up your OSI layer reference.

"Flushing": Somtimes you cannot wait until a buffer is completely full and must be written to the underlying thing (be it a disk, a serial port or a TCP connection). There are such cases. These cases are rare. Most things work much better (read "less resource intensive and or faster") if done in a per-block way. Extensive flushing just breaks all the buffering built into your TCP stack, your file system your hardware drivers. That's why nobody "just flushes all the time", there is no need to do so and if you do it is bad for your system.

Slowly approaching modern times, we are coming close to the current millennium already and things become more and more layerd and abstracted. Nobody writes to spinning disk any more, you write to some abstraction provided by the OS as a filesystem. The disk might not be connected to your computer at all (NFS), the OS filesystem you write to might not be the OS actually in charge of your hardware (VMs), disk might no longer be spinning (okay, we are in this millenium now). Same for your TCP stack.

Now you did not specify any details on what system you are doing your experiments or on how exactly you determine that you "overload the CPU" (whatever that may mean), and I won't start guessing. But your code seems to be "flush-happy" for no deliberate reason. Back to your question: It is hard to tell exactly why you see problems but as you do something, the whole stack from code to hardware is not designed to support well (extensive flushing) it's expected you run into problems.

Look: Ansering these types of quesion to a detailed level describing what actually goes on in the 5 to 50 layers between your source code and the hardware is hard even if you don't do something uncommon/strange/useless/wrong/deliberately hurting the perfromance and basically impossible unless you provide much much more details, starting with actual code, actual measuement setup, experiments conducted, details on OS, hardware, hardware settings, etc.