In fact I recently completed a migration away from Docker/Kubernetes to an AWS stack that doesn't use anything higher level than autoscaling groups and it has been a positive experience. The same application is now faster (less layers necessary), easier to deploy (we own all the moving pieces), easier to debug in production (I can use strace and tcpdump without trying to install them in an already running Docker container), etc. All of the "complexity" that Docker and Kubernetes were handling for us has been replaced with a ~ 500 line Python script that's mostly comments (you can see an early prototype of this script in the repository below, named deploy_build.py, which omits some error handling but weighs in at ~ 150 LoC). Furthermore, now that we have to think about how to package and deploy our application to production, the incentives are there to follow proper Python best practices around packaging (i.e. use packages, don't make assumptions about paths, etc) which has been a nice bonus.
Containers (and Docker, Kubernetes, etc) are all tools that have their use cases and corresponding tradeoffs. Anyone who can't explain when or why you wouldn't want to use a tool is not prepared to explain when or why you should use it.
Obviously, Microsoft also saw your same vision of containers being so unnecessary that they also decided to build the concept into their OS as well.
This concept can't be done on bare metal. Additionally, because it is built into the kernel and they share the same kernel, they generally startup at over 10x performance of traditional VMs. There are solutions now of course to boot directly into the kernel from a hypervisor, but these are generally paired with container solutions as well due to the orchestration and ecosystem that exists to make container orchestration easy.
Most container solutions use a unified image solution that allows you to rapidly reiterate and test your changes in multiple environments. Doing this on bare-metal or VMs takes considerably more time and money for fixed infrastructure costs.
With container solutions such as Kind and Helm, you can rapidly deploy a local cluster to pre-test cloud rollouts on a single machine. The orchestration can also autoscale clusters horizontally and vertically, and is robust enough to directly compete with other bulkier VM orchestration solutions such as OpenStack.
With automatic certificate rotation, automated service discovery, etc there is no need to try to create tasks for every little thing you'd need to do with Ansible or another IaC component. It is all baked into the Kubernetes ecosystem.
Abstraction away from cloud-specific solutions can only be seen as a good thing. People that are invested in AWS generally can't be trusted to create holistic solutions.
In particular, it has been useful to move our engineers to developing using it. We'll probably experiment with using it in production for a few things at some point, just for consistency, but it buys us zero value there otherwise. (We will never run "in the cloud" because it would be cost-prohibitive, at least with current cloud revenue models.)
There will be another new shiny in a few years, at which point the True Believers will move on and tell you how you'll lose your job if you don't get on board that train, too.
Do you have a technical argument to put forward?
For the difference of Docker and reinventing OSes, it depends on what you establish as reinventing OSes. Docker provides some form of separation/containerization, a function that is also implemented by some OS. But it's discussable of having the functionality in user or kernelspace or having a wrapper application with a consistent api across multiple operating systems isn't worth it.
Then why? I mean, I put it in parentheses for a reason man.
I mean, you seem to be saying that I can't tell the difference between automobiles and, what? horses?
Surely if the difference is that great it should be easy to come up with lots of solid points to "change my mind"? Since you're taking the trouble to comment anyway?
In your sib comment https://news.ycombinator.com/item?id=23071602 you seem to be making some solid points, but from my POV it still sounds like "learn the thing" where "the thing" does what I can already do without it, or it enables me to do stuff that I'm not actually interested in doing.
Bottom line: if you want to argue please do it with facts and not dismissive condescension. (I've got plenty of that already without your help, thanks.)