You...do have all the same abstraction layers, right? No? Oh. Well, don't worry, Google/Amazon/Microsoft can sell you those if you don't want to pay your IT staff to prop it up for you.
---
Look, snark aside, yours is the correct take. Google's solutions are amazing, but they're also built for an organization as large and complex as Google. Time will tell if this is an industry-standard abstraction (a la S3 APIs) or just a Google product for Google-like orgs/functions (a la K8s).
One that I retired was used for serving ftp(among other transfer stuff), ftp of all things, it needs to have ports open and routed back from the client. And for extra points they had the pods capped at 1 cpu. And I had to explain the thing to the perpetrator and their boss, madness.
It must have been a while ago - FTP was practically killed the moment browsers stopped supporting it.
I have no love for the original bash scripts that booted the cluster from your dev machine.
Now we also have k3s that is a easy option for self hosting something simple (like homelab).
I would place Google ADK in alignment with Kubernetes more than this project, for the well designed abstractions, the controlplane, and handling the boring parts that every alternative will at maturity.
I can see the agent framework ignorance to the container analogy about what's running inside. ADK lacks the ability to run any agent tool, but you can build most of this projects controlplane on top of it with minimal effort, most of the bookkeeping is there already. It's more about what experience you want to have.
If someone wants production K8s, I'm steering them (and their budget) to a managed control plane from one of the major cloud providers. Trying to prop it up locally when it really hates having to work directly with bare metal does not spark joy.