Obeying the speed limit
Everyday Salesforce.com publishes the number of transactions that take place on their servers, and the average speed in which all those transactions take place at http://trust.salesforce.com. For years, the average speed has consistently been well under 300 milliseconds. This extremely fast speed has remained the same despite the number of transactions growing to nearly 2 billion (with a B) per day! In general, the page load time for web pages is usually calculated in seconds and not in milliseconds, and the same is true for pages on the Salesforce1 Platform. It doesn't take a rocket scientist to figure out then that for every page that loads in, say 3 seconds (a published best practice), there's got to be a very large number of transactions that are occurring in well under 300 milliseconds to balance it out. It's these extremely fast transactions that we care about because they are happening via Apex not through web page loads. It doesn't really matter how fast they are occurring. We do know that they are much faster than the published average, and they seem nearly instantaneous to the human eye.
The average transaction speed is a big selling point of the Salesforce1 Platform and a big source of pride for Salesforce.com and their technical staff. When Apex was first released, it was revolutionary and nothing like it had been done before. There was no way of knowing the effect of letting anyone run their own code. Customers rely on the Salesforce1 Platform to run their businesses, so the folks at salesforce.com couldn't risk anyone negatively impacting performance. The solution was clear; all Apex transactions had to stay within strict limits. These limits governed our usage of Apex and restricted the number of operations that could be performed, the number of records that could be operated on, the number of script statements that could occur, the amount of memory that a transaction could use, and much more.
Note
Amazon's EC2, infrastructure as a service, was released in 2006, slightly prior to Apex. However, virtual servers and platform as a service are different offerings. More importantly, the hardware and software behind the Salesforce1 Platform is very different than that of Amazon's. So any published data at the time would not have been a reliable source of estimates for the likely effect of Apex utilization on the salesforce.com servers.
Those of us who programmed in Apex in the early days would often spend more time rewriting our code to avoid the governor limits than it took to write the original version. The limits were so severe that we were forced to use clever techniques to get around them. For one client, the only way to avoid hitting the limits was to have the trigger perform only half the operation, and then use Apex to send an e-mail to a custom Email-to-Salesforce e-mail address that invoked the second half of the process. This type of juggling was common, but is no longer needed.