Yes, basically all buffering should use work-or-time based flushing.

Work-based flushing exists to batch work to amortize overhead. It allows you to tune how much time you spend in overhead in a work period. However, this can result in unbounded delay.

Time-based flushing targets a worst-case latency in low throughput environments. This ensures you do not get unbounded delays. Interestingly, this also allows you to tune how much time you spend in overhead in a work period.

So, with work-or-time based flushing what you are really tuning is how much time you are willing to spend in overhead in a work period and balancing that against latency.

As a nit, the article calls this a derivative of Nagle’s algorithm, but it is basically the opposite. Nagle’s algorithm is about batching until acknowledgement with no mention of time. In fact, the lack of time-based flushing in Nagle’s algorithm is why it interacts so poorly with TCP Delayed Ack.

> flush the buffer if it’s been idle a short time

I've thought this was the right default for a good while. 50 years ago when Unix was designed, maybe not.

In C, you can use setvbuf to control buffering on stdout. There are also Linux command line utilities you can use to control buffering, unbuffer and stdbuf.