He says quite clearly in the GP. It solved all their scaling problems and massively reduced their costs. With a note that their traffic was particularly bursty.

Does the “lambda per api endpoint” part help with the application boot part or something? Otherwise I don’t quite see what advantage you would with that get over just one lambda for the entire monolith.

OC also mentions that they run a job to keep the lambdas warm. One disadvantage with the lambda per endpoint is that he has to keep dozens of lambdas warm instead of just one.

Dead code/dependency removal. "Tree shaking". If you only serve one route per lambda, you can be (somewhat) sure about what you need and compile the minimal optimized code path for that.

Less "stuff" in each route, less boot/warmup time for each lambda.

I tend to agree that in a lot of cases just sticking the whole monolith in a single lambda is fine, and that's probably how I would do it if I had to do things manually. But as things grow, it becomes much better to tree-shake unused routes, though dead code detection in Ruby might as well be a pseudo-science with all that Ruby can do lol