Ah, this is also a great question.
So, regarding the hashing stuff: password hashing is supposed to be slow, which is why bcrypt / scrypt are so popular.
A lot of people (probably not most HN readers) sometimes don't realize that this can actually cause performance implications on busy servers. Even if you're running a small business on a reasonably sized EC2 instance, handling the password hashing on an already busy server can definitely cause problems if you're serving several requests per second (or more). It's not a big issue, but certainly a real one that many people don't realize they have. (Interestingly, if you use NewRelic and do Bcrypt stuff -- check it out!).
In regards to user data -- you're completely correct. It's not an authentication problem.
I wrote about that quite a bit as I think it's important as user data is also sensitive information. Just like you wouldn't want to leak user password hashes, you also wouldn't want to leak user data.
At stormpath, we provide the data service because we think it's critically important to have your user data secured in the same fashion as your user authentication information -- and as a side effect -- it helps users scale this.
If you're on EC2, you'll likely get the same latency you'd have writing to a Cassandra database locally (with very small overhead) from the Stormpath service. Furthermore, our clients implement really smart caching rules, and can do interesting stuff like transparently handle object caching to a memcached or redis cluster, smartly handle data synchronization, etc.).
Hope that helps!
Also: I really do appreciate these comments, it's an incredibly interesting topic, and it's really useful to hear what other people think! Thank you :D