Watters suggests that developers should build applications that use relatively less CPU and relatively more bandwidth, to keep the network busy. He gives an example where a task takes 10 minutes to compute 1Gb of data and then takes 1 second to transmit it. So that CPU only uses its network for 1 second out of 600 seconds. He sees this as undesirable.
On the contrary. The example shows an excellent optimisation of computation versus bandwidth. You WANT this situation. Also, if you are coding that application, and you can change it so that out of every 10 minutes of computation, it takes only 0.5 seconds to transmit that data, then you should do so. That is an improvement.
In the example cited, the network is only using 0.16% of its capacity. "Idleness of 99.84% is not effective resource utilisation". He is quite correct about that. But wrong to suggest that therefore there is something wrong with that application. Rather, this lets many other computers, running instances of this application or other applications, share the network. In fact, purely from the vantage point of this application, it is good, because it helps the application scale to many instances of it on the same network.
Plus, there is also the issue of latency. Even if the application puts out data at 1Gb/s, that data takes time to reach its destination. Even at the speed of light, this gives rise to times that are often long compared to those times for onboard computation on modern CPUs. Notice also that in many realistic cases, the data has to pass through switches and routers. Adds to the latency. Furthermore, the application would typically expect a reply from where ever it is sending the data so. More delays.
Watters gives his example in the context of quoting George Gilder's law about bandwidth tripling every year. Gilder is famous for saying this, and also saying that bandwidth is effectively free and infinite (or words to that effect). But this is often misunderstood by others, who ignore latency.
All this goes to the core of the book. Web Services are fundamentally a distributed computation, often on machines at different companies, possibly separated by large distances. If you use this book to design a Web Service, it still behooves you to minimise the sizes of packets going on the net, between the different parties. And also to minimise the occasions (frequencies) on which these packets need to be sent. Both factors reduce the overall bandwidth usage and latency. Helps the scaling of your application.