What is fundamentally more secure is running applications inside a VM which is what Amazon is doing. The attacker then has to first exploit the kernel before trying to escape the hypervisor.
operating above these abstractions can save us time, but please stop confusing the artifacts of implementation with some kind of fundamental truth. its really hindering our progress.
You can do everything.
New toolset for containers covers pretty much every possible use-case you could even imagine.
The trend will continue in favor of containers and k8s.
Yes, there is a difference between "eBPF can probe what is happening in L0 of the host kernel" and "you can probe what is happening in other kernels in privileged ring-1 calls".
No, this is not what you think it is.
This isn't about 'what most users care' about either. Most users don't really care about 99% of what container orchestration platforms offer. The providers do absolutely care that malicious users cannot punch out to get a shell on an Azure AKS controller or go digging around inside /proc to figure out what other tenants are doing unless the provider is on top of their configuration and regularly updates to match CVEs.
"most users" will end up using one of the frameworks written by a "big boy" for their stuff, and they'll end up using what's convenient for cloud providers.
The goal of microvms is ultimately to remove everything you're talking about from the equation. Kata and other microvm frameworks aim to be basically jsut another CRI which removes the "deep plumbing" you're talking about. The onus is on them to make this work, but there's an enormous financial payoff, and you'll end up with this whether you think it's worthwhile or not.