Having network namespace is the norm in docker world. Not having that feature is a major impediment. In fact the host only networking feature was added very recently in docker to support some special use cases and that is more of an exception. In docker world, generally different apps may use the same bind port in the container namespace and rely on the dynamic host port to not have collision. And then service discovery mechanisms use the dynamic port.
I would like to see support similar to mesosphere's "mesos-docker" executor feature where it used "ports as a resource" from mesos. marathon would take a ports argument and internally the executor validated with docker inspect the expose ports before doing the NAT mapping. In fact if I remember correctly the dynamic ports were also set as environment variables inside the container. Marathon scheduler did the ports assignment from the port resources.
In general, whether docker0 bridge is used or some other custom bridge, in most cases if slave IP:port is passed and the container passes its private IP and port, there should not be any issue in communication. And I think slave already is binding to all interfaces today (may be wrong).
If more time is needed for this feature, is it possible to not use host networking when there is no executor specified and it would be good to have the functionality as mentioned in mesos-docker above. Because using custom executor within docker is more of a special case i would think. Most cases will run docker containers like regular tasks.