wots_taters
Its not trivial to create your own GAE-like implementation of the API with supporting infrastructure, so prior to AppScale, you had no options if you went down the rabbit hole too far. Now there are two options, but I wouldn't say just open sourcing the API solves all the issues... its the stupendous capacity/availability etc behind the API that people want to leverage in the case of Google.
I personally can't see many other vendors stepping up to write their own implementations of the API, with the supporting infrastructure... its not like the "proprietary" API is good/beneficial, or makes life significantly easier - at least, I didn't find that. I'd certainly prefer the tradeoff of maintaining my own VM/s versus the experiences I had with GAE.
One example is the authentication API being awkward, it seemed like you had to choose [1] either Google's authentication, Google App's authentication or OpenID (you can roll your own auth, its just not obvious from the scrappy admin console - I got the distinct impression they were rushing to bolt things in there w/o putting too much thought into it).
An app written for GAE is going to be pretty painful to port elsewhere as a result of the APIs you have to code to as a result of those limitations (well, now you can port to AppScale pretty easily I guess). The whole thing did feel like a lock-in attempt to me.
I also had to try and estimate the costs a client would face based on requests/minute and some other metrics, and it was tough; basically boils down to 'suck it and see' for a realistic estimate.
For prototypes/pure frontend apps/wikis/static content I'd probably still use it (with some defensive coding to make moving it easier if needed), but I found it pretty frustrating all around when you need to move outside their box.