Very obviously, when the ingress rate exceeds the egress rate (that "traffic intensity" exceeds 1) you've got exactly two options:
- queue the data (with the hope to catch up when the ingress rate slows down again)
- drop the data (and have someone else clean up the mess)
Neither method is the always-right solution.
- You can't queue indefinitely (memory is finite) and large queues have adverse effects on latency and congestion detection.
- Dropping data causes data loss or retransmission which are not desired or inefficient.
The trick is to queue, but size your queue buffer just so that latency and congestion detection are barely effected while keeping data loss and retransmission at a minimum (shallow buffering).
Edit - As your question seems to be really about the queuing/buffering for an equal ingress/egress rate and an eventual buffer overflow:
I suppose, Kurose tries to point out that the internal processing overhead eats into the egress capacity, which in turn causes a slight imbalance between ingress and egress. That was true for (most) software-based forwarding.
However, most modern devices use hardware-based forwarding which can receive, process, and transmit truly simultaneously. So, processing can overlap with queueing (or rather buffering), and the described buffer growth doesn't really happen any more.