not sure about the other versions but working with Java, Lambda is was quite a terrible experience (at least if you needed to include a bunch of jars for your work).
I just finished today to extract a module of my monolith to AWS Lambda in Java. I loved the experience, but first I had to configure a CI in AWS so that the build and deployment cycle was fast.
Since my function needs phantomjs, I embedded the binaries into the deployment package and by just doing that I topped up 36 MB of the 50 allowed. Transferring it from my local regular internet was a pain. Now it's nice, I push code to my dev branch, it gets picked up by the CI, tested, built and deployed. I get a notification in the IDE when the whole roundtrip is done, and with the CI in AWS it takes seconds instead of minutes. Without binaries you can still fit jackson, a few AWS clients, groovy runtime, guava and httpclient in a few megs, which is manageable.
I agree about the debugger, but authoring a function is trivial and unit tests can be written and run without considering Lambda. I miss tailing logs, CloudWatch is nice but it's far from realtime.
I believe the limitation is 50mb compressed/250mb uncompressed. I've never deployed a Java Lambda that's bigger than 20mb though so I've not hit that limitation.
I'll admit that on slow internet connections, uploading a JAR to deploy can be a bit slow though. We have a Jenkins CI build pipeline that automates this process, it builds the JAR (running unit tests etc), then uploads it to S3 and uses AWS Cloudformation to make the Lambda point to the new JAR in S3.
If you need to include a bunch of jars, using Maven + the maven shade plugin (or assembly plugin) to generate a 'fat jar' is very simple.
In fact, their official documentation states exactly this http://docs.aws.amazon.com/lambda/latest/dg/java-create-jar-...