The original article does point out a few reasons, but the way I see it is this: AE is great if you want to scale and your app can scale in the AE way. There is a sweet spot and the tools work pretty well if you're in that sweet spot, but if you stray outside that spot you don't have a lot of options. Even getting your data out can be difficult, making the "export data and start over" nuclear option difficult.
If you know what you're building and you want to scale it using the sort of tools AE provides -- i.e. the datastore, taskqueue, etc. all fits your app well -- it's quite good. And quite cheap; it's not really fair to compare per-resource pricing to AWS because on AE you'll only pay for what you use instead of paying for idle time on a server instance. But it definitely constrains what you can do, and also locks you to a single hosting provider. If you're still exploring what you want to do, that level of design and vendor lock-in can be a pretty severe liability.
Another way of saying the same thing is that GAE is perfectly fine if you know all the requirements of your app before you build it. In a perfect world, you know exactly what you want to build, everything you want is available with GAE, then you go build it and it scales nicely.
In the real world however, requirements change:
* You come up with a new idea that requires a certain library. Chances are, the library won't work on GAE out of the box.
* You find out that you need to change your schema. It is pretty hard to update to the new schema while keeping everything in sync.
Finally, you pay the Google cost. When Google implements a new feature, they spend enormous time making sure that it scales well. They need to do so since they could be looking at millions of users on day 1. Most of us however, are looking to build something as cheap as we can, not knowing whether anyone is going to bother to look at it. However, you have to do the same performance optimizations that Google has to do so that your app scales. Chances are, it will be wasted effort - unless your objective is to just learn. I find it funny that GAE goes completely against the rule that "Premature Optimization is the root of all evil". Yes, you should think about your application's scalability. But your bigger problem should be about finding traction, and being able to react fast, not optimize for millions of views.
If I understand correctly then, it would appear that GAE may be poor for applications that require heavy computation on the server side (say, a facebook style graph, crawling and computing various metrics on it) but great for serving tons of dynamic pages?
If you know what you're building and you want to scale it using the sort of tools AE provides -- i.e. the datastore, taskqueue, etc. all fits your app well -- it's quite good. And quite cheap; it's not really fair to compare per-resource pricing to AWS because on AE you'll only pay for what you use instead of paying for idle time on a server instance. But it definitely constrains what you can do, and also locks you to a single hosting provider. If you're still exploring what you want to do, that level of design and vendor lock-in can be a pretty severe liability.