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.
Lambda is never meant for low latency CPU app, where speed is king, due to startup cost. I don’t see why you would run architecture specific code on lambda.
There are languages like Go, Rust or C that are compiled. If your lambda uses compiled languages you need to recompile to the right platform.
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.
I wouldn't have a task that would quite so extensive on lambda (though tbh I don't know how it costs compared to aws' video encoder service)
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.
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.