It goes back to understanding your users. If you thoroughly understand what problem they're trying to solve and what they normally do when solving it, you can design completely around that and make them happy.
I agree that this is a good design philosophy. But I also think that the problem of "the user not reading the app description" (as described by the parent) is a separate issue.
For example, I found that there were several problems to be solved that were all related to the same domain. Apps existed that do a decent job of solving problem X. So I wrote an app to solve problem Y. I have received numerous 1-star reviews because the user is disappointed that my app does not solve Problem X. In my case, I am pretty confident that I clearly described the problem solved by my app. I even explicitly say that it is not meant to solve problem X.
I have also received many positive reviews from users looking for an app that solves Problem Y. So in my case, I don't think it was a problem with understanding the user.
This might describe a supernatural level of user-understanding; but it must be possible to create an app description which gets past the barrier of what the customer expects your app to do, and actually communicates to them the true capabilities of your app.
I'm just speculating, but it's possible that the people who misunderstand the purpose of your app because they didn't read the description are people you never intended to be part of your demographic of users. For [a hypothetical] niche-puchose software, catering to idiots may be very detrimental. I could imagine a situation where intended software goals and mass market acceptance would never line up.
