The reasons for different lexical and structural choices are going to vary from language to language, as are uses terms like "module", "package", "namespace", and so on, but a key distinction between module access and member access is often that module access is static:
a::b definitively statically resolves to an element of that module. It's not so much about knowing that the thing on the left is a module as knowing that the lookup is manifest and that this specific entity is referenced. This can ease static analysis tooling and make local analysis by the programmer simpler, but it's not necessarily an essential distinction.
In Java, which uses
. for all navigation,
java.lang.String.format("") could be calling
format on the
String class inside the
java.lang package — or it could be a call chain starting with the
java field of a superclass, and there's no local way to tell which is which. You have to do inheritance resolution to know which is happening. On the other hand, the compiler will be doing that resolution anyway, and the
:: token was left free for method references later.
import statement can bind some exported declarations into an object. That object is first-class and you can do anything you could with any other object to it, including pass it as an argument, alias it, introspect it, and dereference members of it. This is a genuine semantic difference from a static module system, including Java's; the ability to
export default a function, which then needs to act like a function, is also a novelty. The module system was also retrofitted into the language, to replace various proto-module systems that of necessity used objects, so easing the transition is a factor — although I'm not sure they'd do it any differently regardless.
Not every language draws this distinction, or has the sort of module system where the question comes up. It's clearly not essential, but languages do make lots of design choices to match their priorities that aren't essential.