Doesn't exposing the hardware under the lambda kinda defeat the point of the lambda?
And lambda is more about changing the process lifecycle from traditional always using resources. Sort of the inetd for hyperscalers.
If your container runtime uses an emulator (say QEMU) you are able to run containers which do not match the host system, albeit at a slower speed than running the container using a matching architecture and namespaces.
If you can compile the single task your lambda will perform down to as close to bare metal as possible, without affecting your workflow, why not?
I use JavaScript in the few lambdas I have because of dev. ex. What little additional cost it would add offset by speed of development for me, and how important speed is to my tasks.
But in a similar vein, extracting interesting thumbnails would at scale, be one use case where lambda with assembly/compiled static bins may be a good choice.
Additionally, a lot of interpreted languages depends on native libraries. You need to build those libraries using the right arch. It happens a lot if you want, for example, deploy a Rails app in Lambda.
By the way, Lambda works great for low latency apps. The "startup cost" is negligible if you know how to implement it. You can serve ML models from a lambda, and in that case you want a math library optimized for the platform. Unless you have a lot of traffic a Lambda usually is cheaper.
Overall, I see that as a win: you can get started by putting code in something like Python or JavaScript and not caring but when you do hit more complex dependencies you have a path which is an extension of what you've already been using rather than having to switch to a completely different service like ECS.