I recently replaced the SAS drives in all of my database servers with SSDs. Watching IO wait on my usage graphs drop while db latency fell to near-0ms was such an incredibly gratifying feeling. Worth every penny.
If you've got heavy random IO on your dataset (90% active, OLTP here) and/or deal with any sort of significant contention or deadlocking across your disks, I would strongly encourage upgrading to SSDs. Of course, if you can fit your dataset into RAM, go that route. But if you're well past that point, might be time to consider SSDs.[1]
It's quite impractical for them to "support" SSD. The way (I assume) their infrastructure works would basically mean that the speedup you get from SSD would be nullified by the rest of the IO needs imposed by their stack. That is, if they were to simply move one service (in this case, EBS) to SSD.
The only way I see this happening is if they start adding servers with SSD, where all services running on those servers support SSD too. This would basically mean a separate cluster, fully based on SSD. I don't see this happening soon.
They don't have to move to support EBS with SSD and mix and match. They could have RDS instances with SSD only option and EBS based on SSD. They can charge significant amount for those options, some might even pay for it.
If you've got heavy random IO on your dataset (90% active, OLTP here) and/or deal with any sort of significant contention or deadlocking across your disks, I would strongly encourage upgrading to SSDs. Of course, if you can fit your dataset into RAM, go that route. But if you're well past that point, might be time to consider SSDs.[1]
[1] http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-m...