The simplicity of the API and data model really appeals to me, it kind of just does its thing well and doesn't try to be the perfect database for everything. After learning how it works, which you can do in the docs as well as the original dynamo whitepaper which is very good, it becomes pretty clear where the tradeoffs are.
Once you get a system built on top of dynamo, the big upside is you actually get pretty much unlimited scalability just by turning some knobs as you grow.
Because it's so simple and forces you to work within its framework, it just feels a lot more solid and predictable than other marketing-heavy datastores (MongoDB being the one I've been most burned by, though I haven't used it in years now so maybe it's better) that promise scalability but also try to do everything and so offer a lot of features for the single node case without making it very clear which features you need to avoid using if you want to run in sharded mode.
And then aside from data model, that fact that it's hosted is amazing. I set up a Cassandra cluster a few years ago and it took weeks just getting the JVM running stably with the right GC generation sizes, setting up monitoring, etc. As of a year and a half or so ago, DynamoDB now has basically all the features that Cassandra does (the notable new additions being set and dictionary types that you can use for some kinds of CRDT data types).
It also works well with Amazon Elastic Map Reduce - you can run a huge Hadoop job, say, and output the results to s3, and then turn up the writes/sec very high temporarily on DynamoDB to write the results to dynamo quickly, where they can be used in your app.
The downside to dynamodb is that you have to structure your data as simple key-value lookups, and this makes some things that are simple in SQL databases, like adding an index to query a new field, a little harder in dynamo. There also are no joins, so you have to do any joining you need either in memory or by duplicating data and denormalizing.
Again, it's not the perfect database for everything. Particularly if you have a system that you expect will always be well within a single server's capacity, and you want to be able to do OLTP and OLAP workloads in the same place, using a SQL database probably makes more sense.