A misconfigured site that serves all its own assets will perform terribly because 200 hits per minute x 20 assets = 4,000 hits per minute. Wordpress has tons of assets too.
The approach I've been taking with my recent projects is to serve all static assets from Amazon S3/CloudFront. That way 200 hits per minute is only 200 requests. 19 of those 20 assets in your example would get served from the CDN. I don't have a lot of experience building robust apps (I'm a self-taught hobbiest developer) but intuitively this configuration makes sense and it has been incredibly easy to implement. I did some stress testing for the first time on one of my apps using jmeter and was able to achieve much higher performance that 200 hits per minute on my free micro instance.
Never used WP, but aren't those static assets? The bottleneck would be bandwidth then, should not be a huge load on the server. If it's compiling stuff or fetching them from DB though, then that could cause some problems.
It has to do with the number of requests plus the number of allowed processes plus the requests each process was allowed to serve. At a limit of 300 requests per process, the processes fell over at about 3 seconds time. With only 20 processes, dying every three seconds, the server was overwhelmed. So it's really a combination of issues.
Looking at the records for MySQL data, there wasn't that much of an issue there with MySQL connections. This is probably due to the fact that the page cache was working correctly.
I think that most people leave it configured for default and never bother to do any kind of caching. My server was down less than five minutes because I knew what to look for.