I agree with your arguments in that if your stack is already built on Docker it's a lot to ask to move to a different system. But if you are choosing a new stack for a new project, why not look at alternatives to Docker? There are many and jails is a good one. Granted, I haven't looked much at orchestration tools for jails.
As far as do you need Docker in the first place? Well maybe. One of my favorite orchestration and deployment systems I built was based on packaging everything as .deb files and running our own apt repo. Since all workstations ran Ubuntu and all servers ran Ubuntu getting our system up and running was as easy as adding our custom repo and running `apt-get install our-custom-project`. apt is great for resolving dependencies and this way we don't end up with a mess of files all over the place. Plus this way we got all the benefits of not having to update every container when a libssl update was required. Just run `apt-get update && apt-get (dist-)upgrade` and suddenly you are fully up to date and restarted.
Orchestration on this system was accomplished by using puppet to set up the custom repo, install the packages, install all the current config files for the system services as well as our own, and starting all the services in order. Reproducible to the point where when one of our servers (we had a few pieces of beefy physical hardware) blew up, we simply set up a new one, ran the puppet manifests and were back to full capacity within like an hour. Mind you this was back in 2010-2012 and tooling has only gotten better since.
This type of thing also allows you to nicely package any custom versions of software you want as well. Want a custom build of nginx? Go run the script that builds it and makes a .deb out of it, then upload to your repo. You aren't relying on some guy with a blog post to keep his server up. You aren't even affected by GitHub going down if you don't host your apt repo there. Or use it out of a PPA someone else maintains. But there is zero need to wget/make/make install with this setup. You aren't doing reproducible builds because it's a build once, run everywhere system. And it makes you very directly consider what your dependencies are. Do you really need that unmaintained library written in an esoteric language that requires a SPARC to compile? Docker allows you to hide bad dependencies behind the idea that they are inside a container so the harm they can cause is limited and the headache is localized. But that just treats symptoms, not the problem.