I agree that people should not blindly turn off buffering, but to be honest it will lead to fewer problems for most people than blindly leaving it on. The main issue I have with what you say is that you need to know how the program will be used in the future before you can safely leave it on, and this is not easy to do. For example, buffering will keep a script from effectively being used in pipelines when the data arrives in a time-sensitive manner...

tail -f slow_growing_log | grep fiz | my_script
[download]

With buffering on, it may be a long time before I see a log message I want (Update: after my_script processes it in some way) even though it's at the end of the log file. If I kill the pipeline I may never see the output I want. Perhaps a lot of people don't do this kind of thing, but I find that I use scripts in pipelines where I wouldn't use them in the past. FWIW, I could turn your argument around and say that you should always turn buffering off unless you know you need performance (i.e. you profiled it), since it could be viewed as premature optimization at the expense of compatibility, but I think that argument is a little strained.