What you appear to have overlooked is that this arrangement doesn't actually run the web server in Lambda -- that is not even possible because Lambda functions do not have a daemon mode.
A Lambda container that is not currently handling a function invocation is in suspended animation, being denied access to the underlying CPU. It can't listen on a socket.
The web server is AWS API Gateway or Application Load Balancer, both of which accept viewer requests and use their payload to invoke a Lambda function. There's no need for Nginx but, technically, you could still use it, it would just be quite pointless... but CloudFront is a nice serverless reverse proxy that can, say, send requests for /assets/*
to an S3 bucket while sending everything else to the application behind API Gateway.
So the argument that this isn't the intended purpose seems premised on a misunderstanding of what's involved.
Also, AWS has an official library for exactly this purpose.
Run serverless applications and REST APIs using your existing Node.js application framework, on top of AWS Lambda and Amazon API Gateway
https://github.com/awslabs/aws-serverless-express
...so it's a perfectly valid use case for existing applications, at the very least.
For new applications, including the framework is more debatable since it's a layer of overhead that isn't strictly necessary, but the rest of the architecture is unchanged if you omit the framework -- you can build a complete web site on Lambda functions, in Node.js, without Express, and it's largely the same setup. The web server is API Gateway or ALB, or can simply be CloudFront if you are using Lambda@Edge for your JS or Python code.