Indeed. You want to have small buffers, because big buffers increase WIP (Work In Progress), product gets damaged, problems are hidden, etc. That follows the JIT (Just In Time) ideas. But, you still want to have buffers to decouple both operations. You also want to constraint the size of the buffer, where the producer stops when the buffer is full. In the case of queues (As in AWS SQS), I am not aware of any limits where you can also stop the producer when the queue reaches a size. I believe it is desirable just from my experience on Manufacturing systems back in the day.

Reducing buffer size puts back pressure on the whole system, which can be valuable to manage load (but often throttles faster stages and that throttling makes people uncomfortable). A meaningful metric is how much of the buffer is used at any given time and the throughout. If the buffer is backed up, that says there's a bottle neck on the consumption side of the buffer and more bandwidth is needed there. For whatever reason, adjusting buffer sizes is the more common action taken. A buffer provides throughput management but it also provides info/metrics about the operation of the system.

You can also observe this in games like Dyson Sphere Program, (which is all workers and queues and buffers) where adding a buffer storage section of a belt only hides the fact that you are under-producing one of the components required.

The buffer smooths out bursty flow but you don't want that in the middle of the pipeline, as it actually represents mid-pipeline inefficiency. You should actually be fixing the upstream or downstream problem.

[1] or other automation games like Factorio, Mindustry