hmmm layman’s terms see if this makes sense
--net=host will in short remove all network isolation from the container, so if you start an application on port 3000 anyone who can connect to your host will be able to connect to that port with out you have to add any additional flags to your docker run command, the container basically works like you were operating directly on the host, except you have an isolated file system still.
So the problem with this is you lose isolation of your application so say for instance you want to start up 2 postgresql instances which is configured to start on port 5432. If you started the first container with --net=host, no problems the container would start happy days, but when you went to start the second one it would fail to start because 5432 is already in use.
So just remember with normal docker bridged network the container can connect to anything the host can, but you have to configure what world is allowed to connect to inside your container, this allows you to set up 15 of the same container all listening on port 3000 inside the container, but you tell the docker engine to expose port 3001 on the host and map that back to container 1 on port 3000 so it allows you to scale your application with no application config changes.
When would you use --net=host? maybe if you wanted to spin up a empty container and play with a new tool and you didn’t know at the start what ports you might want to expose, or you have some network debuging tool and you want to have direct access to the network interfaces on your host.
As with all things in Computer Science the best way to understand most things is to Experiment! See what works what doesn’t work and have some fun 