I'd like to hear more about this rational. With a single writer, buffering channels can help smooth out inputs when the p90 is much higher than the average with channel writers but not readers. At least that's my impression.
The former is a reasonable concurrency primitive. The latter superficially seems similar, but is actually a much more complicated primitive, with the corresponding code understanding problems and the increased likelihood of more concurrency problems being hidden at low scale but coming out at scale (mostly deadlocks), plus the fact it seems similar is also problematic. The fact that the Go type system does not allow distinguishing between the two is also problematic.
It has some special-case purposes, but I also always scrutinize any channel created with buffering to make sure it is one of those special cases.
Buffered channels have not impressed me with their ability to do any sort of performance improvements. In almost all cases, if you've filled up your readers, you really want your writer to block. It provides cheap, effective backpressure; arguably for software-at-scale it's the most useful aspect of the channel primitive.
The other reason to use them is controlling CPU. Spin up a pool of consumers and control how many cores they use with the buffer.