I guess most of tech articles in general often pay more attention to technology details than to its cost-effectiveness (or even TCO) for certain classes of workloads.
If your workload is a 'traditional' web application, saturating a full VM and not too bursty - don't run it on Lambda.
Regarding vendor lock-in, I don't think Lambda is important for the vendor lock-in question. If you just need 'compute' capacity, it would be easy to move from Lambda to anything else. But if you also use bunch of other AWS services - then moving the Lambda functions is likely to be your least concern, frankly. On the other hand, if you do leverage various AWS services (other than just IaaS) - switching to Lambda (or other managed platform) could be useful to make your entire architecture (more) serverless.
If you expect a steady load of hundreds of requests per second - maybe API Gateway + Lambda is not the best solution. The use-case in the article did not have such load targets. Lambda is not a silver bullet..
Actually we have started doing some initial exploration of such an architecture. But don't have results we can share yet. Maybe in one of the follow-on blog posts :-) I agree that it could make a lot of sense in some cases.
The serverless.com framework helps addressing #2,#3,#5. There are other frameworks that help addressing #1. Not sure what kind of compatibility or incompatibility do you have in mind for #4 - you could access RDS from Lambda if you really want.
I think "all the love" is related to the fact that you can enjoy the variety of AWS services (which does not exist to the same extent on GCP, at least yet), and integrate them together relatively easily. Also, from developer perspective, AWS documentation and SDKs are by far superior to those of GCP (at least from my experience).
GCP does have many advantages around specific features/services - but at large, AWS is (still) much more capable and mature.
Disclaimer: I am the author of the above article :-)