This is such an insanely short-sighted and downright ignorant statement to make. Not everyone is working with highly abstracted "web applications". If your entire infrastructure doesn't think of anything lower than HTTP, sure. But the industry is so much larger and there are so many reasons to care about the actual hardware your code runs on.

Code runs on computers, and cloud is just a single word for "someone else's computer". Great, you've outsourced hardware provisioning, maybe even OS patches - that's smart, this is not your core business, just like toilet plumbing isn't. But you still need to hire someone to carry a pager, and when the plumbing fails, that person needs to understand what exactly went wrong - sometimes at 3AM on a Sunday. Engineering and operations is not just layering abstractions, we've had Lisp 60 years ago and yet it didn't solve everything.

I think the future is some BEAM-like VM abstraction for cloud environments. I worked at a 100% AWS serverless place and the current tooling is terrible. Now I'm working in Elixir and it offers so many of the tools I wish I had when working there.

Some infrastructure decisions need to be made by app developers.

For example, anybody with hard security environments (finance, healthcare, defence) needs to make sure that some services aren’t available on the public internet but are capable of communicating with internal services.

This kind of networking requirement is essentially tied to the application layer - only application development organisations can know whether e.g the service to check why a user is banned should be on the public internet.

Such a decision could be expressed by app developers using infrastructure as code, UI toggles or physical buttons in a DC - but it has to be their decision.

Similar logic applies to DNS, data isolation, backup policies, caching strategies and much more.