It’s not necessary. You can just stick the setting in a file somewhere, anywhere, your choice.
The complexity arises if you want that setting to be associated uniquely with a package, because the package system is complicated. (All good packaging systems, in every language, are complicated!)
A key complication is that Julia can have multiple versions of the same package installed simultaneously, and the user can rapidly switch versions by changing project environments, and can run in different environments simultaneously on the same machine. So there is no single place that a package is installed. Moreover, a package might be “hidden” because it was only installed as a dependency of another package, so that the user doesn’t necessarily need to know that it is exists or where it is. And such a hidden package should be automatically deleted when it is no longer needed. And some packages might be in a read-only location (e.g. installed by a sysadmin).
So, to associate a preference with a package, the preference really needs to be per project environment as well, so that diffferent versions of the same package (or the same version in different environments) can have different preference settings. (After all, the meaning of the preference settings might change incompatibly between one version of your package and another.)
You can still do this in Julia. You can discard the whole package system and all its benefits and just give users a script (or a module as raw source code in a directory) and tell them to edit a file.
But then, of course, you lose all of the benefits of a modern package system: automatic dependency management, version management, environments (which are crucial to avoid “dependency hell” when you’re using different software with incompatible version requirements in different projects), automated precompilation, and more. Nearly every modern language seems to have a complex and full-featured package manager (Rust Cargo, RubyGems, JavaScript npm, Python pip and conda, …), usually after years of painful development with more primitive solutions. Really, we’ve tried going without, and in the long term it sucks!
@sswatson had some good advice in another thread: