The current usage of
export has two (related) roles:
a shorthand for documenting the API (“this is exported so you should read its documentation, this isn’t so think before you use it”),
quickly importing a consistent set of nouns and verbs that was determined by the package authors to be useful, with various trade-offs in mind (eg conflicts with other packages).
There is no consistent standard, so the package authors rely on tradition, example, and their own preferences about what to export.
I think that writing good documentation and a consistent API with a few symbols that need to be
imported explicitly makes no explicit
exports viable. Some packages indeed do this; AD is a good example.
OTOH, some packages (and collections of packages) cultivate a consistent API that is exported, and make sure that there are no conflicts; sometimes with the use of packages with the sole purpose of defining and exporting some skeleton of a generic interface. JuliaStats is an example of this.
I think that the point you are making is valid. On the other hand, some languages treat their namespaces differently, eg in
R the whole API is imported by default for libraries, so most users don’t even need to think about namespaces. For users coming from these languages, starting everything with a set of
imports may be unusual, especially in interactive use.