GAE is a massive lock-in with outdated software in a world where there's so many better, cheaper, non-lock-in alternatives, even within Google itself.
The GAE team has been (admittedly slowly) pushing the services that were GAE only into being fully-consumable "Cloud Platform" services (e.g., Cloud Datastore is the same Datastore that's been "part of" App Engine forever, but now accessible from anywhere).
It's your choice to use Datastore, and I respect that you would chose to avoid it, but the basic PaaS idea of "here's some code, run it for me as a web endpoint" is still compelling even today.
Disclosure: I work on Google Cloud.
But to answer your question, I don't know anything about that Amazon service but I would feel the same way about similarly-designed competing product. IMHO, no informed person would ever pick proprietary, lock-in-heavy PAAS solutions.
Is your concern the lock-in from the code standpoint, or operational "lock-in" that once you've got all this set up for you, you'd have to go replicate it to get out? If the latter, aren't you saying you're going to do that on Day 1 in the "avoid PaaS" case?
This sounds like your personal bias and is clearly not true. Business doesn't work like this and you would be surprised if you looked at just how much proprietary software runs the world.
Lock-in isn't a thing to fear, it's a natural spectrum of using any service. The more specialized that service, the more work will be involved if you need to move away.
The real question is if the risk is worth it. Do you really need to switch? Are you worried that Google or AWS will somehow disappear before your business does? If not, what is the big deal?
You're conflating two things though: Lock-in as a whole, and unnecessary lock-in like GAE's. Yes, lock-in is a choice to make and not always an incorrect one. But I can safely say no informed business should/would pick Adobe Flash over HTML today for, say, internal web apps. Adobe Flash is fairly old and legacy technology, deprecated in all but name for that scenario and includes a fairly significant amount of lock in due to its proprietary nature requiring you to rework your entire application were you to change to an alternatire. Sounds familiar?
You weigh the risks and see if the potential work (that might not ever need to be done) is worth the benefits offered today by that service. That's what an informed business does.
There is an opensource reimplementation of App Engine's interface. That said, I have no clue about its completeness or buglessness.
As I see it, at the time App Engine was introduced, there were a lot more comparable PaaS offerings (maybe not with the same languages support, but the style of PaaS that GAE is was more common.) Competition from GAE and Heroku (which originally was focused on a similar PaaS offering) seems to have driven most of the other alternatives to pivot to something else or fail entirely.
Right now, there's very few close substitutes; there's lots of "alternatives" that require more infrastructure work (e.g., IaaS and similar offerings like GCE, GKE, EC2, etc.) or are off in the other direction ("severless" function hosting like Lambda or GCF.) And in some cases these might be better options than an GAE-style PaaS, but they aren't really direct substitutes, and they leave a space better served by GAE.
Since App Engine comes with a proprietary data store, ORM and task queue built in, skipping the Appscale compatibility thing and just porting a large application to run on another platform would be a herculean effort. The data store models and everywhere in the application code that they're queried would need to be re-written for a different ORM, all of the data would have to be migrated to a different store, and all the background tasks and methods that trigger them would need to be rebuilt. This would be thousands and thousands of lines of hand-edited code changes, before even thinking about how much time would need to be spent verifying all of the changes.
At least with Heroku the magic is mostly around deploying and scaling the various pieces, rather than providing a lot of application level libraries that lock you into the platform. Porting to another platform likely would require a bunch of configuration management and some deployment scripts, but fairly limited changes to the application code itself.
Generally we find that any buildpack written for Heroku will work with Cloud Foundry without modification. With a little extra engineering you can create a buildpack that will run in a fully disconnected environment.
Disclosure: I work on the Cloud Foundry Buildpacks team on behalf of Pivotal.
AppScale will allow you to move your application (unchanged) and still reap the benefits of the App Engine model, autoscaling and all. I still believe App Engine benefits trumps any other PaaS out there.
Within Google, either of the GCEs (https://cloud.google.com/compute/ https://cloud.google.com/container-engine/) depending on your architecture.
I'm not saying "Don't use GAE because it's expensive/google/whatever". I'm saying "Don't use GAE or anything like it".
Cloud Foundry gives you the "just push" experience for both of these (as well as vSphere, OpenStack, GCP and more to come). It's open source, with the IP owned by an independent foundation.
Disclosure: I work for Pivotal, we donate the majority of engineering on Cloud Foundry.