On a more serious note though, both technologies have their uses. Docker can be nice for ad-hoc hardware provisioning without needing to think about much, but I think the GP's comment is still relevant. For a lot of users who are completely unfamiliar with bash/Linux, Docker will be impossible to grok. For the average HN engineer sitting at their Mac, it makes a lot more sense to get nginx/apache from Brew and tinker with it natively.
I'm not fucking interested in "tinkering" with nginx/apache to host my own software, I'm interested in herding dozens of open source applications that replace paid/shitty ad driven SaaS companies.
The contract with docker is incredibly simple - you give me the path you're saving data to, a couple of ports to point at, and some ENV vars to provide config - I do the rest.
Boom - suddenly I can easily host literally hundreds of dollars per month worth of recurring subscription SaaS products using my own hardware and networks. All without having to see ads, or risk external data breaches, or deal with user tracking.
Which is the point, when the goal is to self-host someone else's application.
If you're just interested in learning how networks work, or what http is, or how to write software - then sure, go tinker with apache or nginx.
If you're trying to self host, containers are great. They do exactly what you've said - applications become (mostly) pushbutton components where the contract is simple and clear (data/ports/env).
And yes - there certainly is a bit of a learning curve for containers, but I'd much rather learn containers once than have to learn the ins & outs of the 25 apps I self host. For the most part, I neither want nor care to learn how they were put together. There simply isn't enough time, and the value is low.
Again - the goal here is NOT to host a blog/website I've made. It's to self-host applications other folks have put together, and that seems to be where this reference can be valuable.