I think EC2 and Rackspace Cloud serve two different groups. EC2 is the only provider on which I've actually been able to boot 50 nodes, have them come up in a few minutes, use them for an hour, and kill them all off. That sort of thing would be a giant pain on Rackspace Cloud, since they e-mail you the root password when you boot an instance. Also, Rackspace Cloud accounts are limited to 50GB of RAM usage unless you contact them to increase the cap. (Rackspace only mentions this in their API docs: http://docs.rackspacecloud.com/servers/api/v1.0/cs-devguide-... See section 3.8.2: Absolute Limits.)
Still, most small and medium-sized companies would do best to go with Rackspace, Linode, or something similar. You'll get better support from them and it's not often that a 10 person company needs a ton of servers for a short period of time. Even then, you could use both: short-lived instances on EC2 and stable, well-supported, long-lived stuff on Rackspace.
It's actually quite easy to spin up multiple servers from a pre-existing Rackspace image via the API. The initial POST to create the server returns the password, which your script could either capture, or you could send a PUT command to the /servers/id URI to update the root pass to be whatever you want it to be.
That's not my only reason for preferring EC2 for lots of short-lived servers. I left out some anecdotes.
Four months ago, one of my coworkers booted 12 cloud servers in DFW. I later discovered that 3 of them were on the same physical hardware. Two months ago, about 55 of 60 servers actually came up in ORD. Others were inaccesible or hung. Not even hard reboots helped. We had to kill them and start new ones.
I've had a total of 2 EC2 instances die on me. I admit my usage of the two providers is quite different. The stuff on EC2 is shorter-lived. But I'm pretty sure that high turnover on other providers would cause a lot more grief.
I've seen literally dozens of unresponsive and defective EC2 instances over the last year. This was spawning 100s of medium and large instances per day, with an average instance lifetime of around 3 hours.
From what I've read during my usage of AWS over the last couple of years, this is more the norm than the exception.
I think we agree then. Dozens out of 36,000+ instances is a very low failure rate. I haven't had nearly that volume so I've only experienced 2 failures on EC2.
In addition the Rackspace API supports injecting a file into the API post request which will be placed into the system as it is initialized. The intent of this is to inject some sort of individual identifier to a server, which could be in the form of an ID number that is read by a boot script in your gold image, but other useful scenarios that would work would be to inject the root password you want or to disable root login entirely and inject an ssh public key file for a non-root account.
Still, most small and medium-sized companies would do best to go with Rackspace, Linode, or something similar. You'll get better support from them and it's not often that a 10 person company needs a ton of servers for a short period of time. Even then, you could use both: short-lived instances on EC2 and stable, well-supported, long-lived stuff on Rackspace.