I think you're both right and wrong. You're right in that if you did run Django inside Lambda it would be inefficienct. But you're wrong because that's not how you should adopt Lambda. This is a similar situation to everybody re-architecting all their single-point-of-failure on-premise apps to the cloud in the first place.
The point of Lambda is that you don't startup Django with each request. You can think of the fixed/shared part of Django being replaced by API Gateway. Lambda then replaces the non-shared threads that get started for each request.
I see where you're coming from, but not all state that could have been shared can be pushed into the API Gateway, like Code Objects and settings. To adopt lambda as you suggest would require a re-architecture (not Django), and at that point you're probably better off going for something more efficient. They even mention that memory cache hit ratio improved giving more CPU throughput, which totally disappears if you're starting a new process for every request.
The point of Lambda is that you don't startup Django with each request. You can think of the fixed/shared part of Django being replaced by API Gateway. Lambda then replaces the non-shared threads that get started for each request.