Facebook photos application for example, can be CPU-bound, because image processing applications had to process millions of pixels efficiently.
In this context boundedness means roughly "the thing that would increase throughput if we had relatively more of it". A pizza shop is going to be fundamentally "oven-bound", because everything else from employees to counter space can be increased more easily than the size of the oven.
Waiting on outside I/O (databases) does not mean that a webserver is I/O bound. The system as a whole might be I/O bound, but not the web layer. Threads stuck waiting for dataz are just put to sleep and others take over the CPU.
But suppose you are generating tons of SSL certificates. You can't --or shouldn't-- cut corners. For example, see
https://freedom-to-tinker.com/blog/nadiah/new-research-there...
So... what do you do? The problem, like almost any bottleneck problem, isn't that you don't have "enough" of the resource, it's that the resource is out of balance with the other resources like CPU or RAM. When you think about it that way a lot of possibilities open up, like installing special cards or dongles that generate entropy, or by buying lots of lower-powered devices that have more entropy relative to their CPU throughput.
I can put it another way:
Some Tilera boards have 4x10GbE ports, but have no good floating point support.
On the other hand Xeon Phi has AVX2 (512 bit wide SIMD) with excellent floating point performance, but TCP/IP stack emulated over PCI-express.
So which one will you choose for network server and which for number crunching?
You can either increase the resource (upgrading CPU, adding memory), or use the resource in a different way/trade off one resource against another. For example, compressing data before network or disk I/O might be useful if you have spare CPU. Once you've done that, you may now be bound by something else - maybe available memory. If you have spare resources (CPU, for example), you can then choose to use fewer/less powerful resources in that space if it makes economic sense.
You can also talk about response time being bound by something - disk seek time, network latency, memory latency, and so forth. That affects how fast something can respond, and while that figures into how much work a server can do (per-thread/request memory usage), it doesn't generally largely affect how many machines you have to buy or their configuration (unless you have low-latency options).