And that's what Docker is built on: processes + namespaces to restrict what each process group can access.
> I look at things like Docker and think, you are solving a completely artificial problem, and as soon as fashion swings the other way (10 years at most) people will wonder why people ever did this.
Things like Docker will still have value with single-executable containers. Problems that people have had for years. Even with single-executables.
You still need to manage privileges. You still need service discovery. You still need to manage the network. You still need to manage data volumes. You still need to manage the environment.
Docker provides mechanisms that either solves all of that, or provides information for tools to hook into (e.g. ability to query what ports the currently running containers expose).
I agree with you that there is distinct benefit in self-contained executables, and I think you'll find a lot of people working with Docker thinks the same. Partly this is part of what Docker gives us: We get to treat a bigger hairball of an environment pretty much like a single entity, even if we're not able to slim it down.
But partly, note that a lot of the adoption of Go within devops tools appears to at least partially be motivated by the simplicity of distribution and installation from getting static binaries (without having to use C). I prefer Ruby, and find Go to be a ugly, too low level, language, but I definitively understand the appeal Go has when it comes to simplicity.
Yet despite having those devops tools as single executables, people want to put them in containers to manage them properly.
If anything, I hope and think that things will move even further down this route. For my part, I'm containerising my desktop environment part by part. There's no reason we should not move to far more locked down process environments.