"100% efficient resource utilization" is a bit over stating it, but it sure is a lot easier to ensure you don't over provision.
Google cloud-run can handle multiple requests at a time, but still suspends the instance while no requests are being processed, and is billed to the nearest 100ms
To flip (because I'm generally pro lambda) the one call per instance also encourages global state (since you don't need to worry about two calls running in parallel using the same memory), which is pretty bad coding practice.
I'm not sure why but I found with pre-compiled languages like Go it's not as big an issue (as long as your app is I/O bound). With Node.js I've found that increasing the size of the Lambda helps even with I/O bound functions. I assumed it was because the JIT compiling of the JS takes CPU but it also seems slower on subsequent runs and Lambda sleeps the apps it doesn't stop them (until you hit the end of the 5 minute reuse window). I give my Node.js a min of 1 Gig of RAM whereas I've been able to get some of my Go functions down to 128MB with no performance hit.
Which yes, means the Node.js functions are about twice as expensive per MS before you even consider that the Go function runs for less time. But in both cases I've still found it cheaper than servers due to efficiency even though strictly speaking it costs more than a server per GB/Ghz.
However, it appears to not only lower the amount of cores available, but the performance of those cores.
So even if your code is very single threaded, and has low memory requirements, you still might want to provision a larger lambda memory size.
The frustrating thing with this, is that your single threaded code might only be using one of up to 6 CPU cores made available to it.
But the granularity is much finer with Lambda so you're closer to full efficiency. No having a server with Gigs of RAM and multi-cores sitting around for hours a day with 10% utilization.