I actually want to use SimpleDB, however i worry that without real securing and transactions the whole product is fatally problematic. I realize that for top-read/low-write applications it seems sensible, since eventually the machine becomes consistent, but how about that point among? Appears such as the right query within an sporadic db would perpetuate havoc through the entire database in ways that's very difficult to find. Hopefully I am just as being a worry wart...
This is actually the pretty classic fight between consistency and scalability and - to some degree - availability. Some data does not always have to be that consistent. For example, take a look at digg.com and the amount of diggs against a tale. There's a strong possibility that value is copied within the "digg" record instead of forcing the DB to perform a join from the "user_digg" table. Will it matter in the event that number is not perfectly accurate? Most likely not. Then using something similar to SimpleDB may well be a good fit. However if you're writing a banking system, you need to most likely value consistency most importantly else. :)
Unless of course you realize from day 1 you need to cope with massive scale, I'd stay with simple more conventional systems like RDBMS. If you're working somewhere having a reasonable business design, you'll hopefully visit a large spike in revenue if there is a large spike in traffic. You'll be able to use those funds to assist fixing the scaling problems. Scaling is difficult and scaling is difficult to calculate. The majority of the scaling issues that hurt you'll be ones that you simply never expect.
I'd prefer to obtain a site off the floor and spend a couple of days fixing scale issues when traffic accumulates then spend a lot time worrying about scale that people never reach production because we exhaust money. :)