I do not agree. It is very often the case that applications have it in their documentation that things can be configured away from the deafults by using process environment variables.
Even a mundane tool as ls has in it’s man page:
Using color to distinguish file types is disabled both by default and with --color=never. With --color=auto, ls emits color codes only when standard output is connected to a terminal. The LS_COLORS environment variable can change the settings. Use the dircolors command to set it.
And from man zypper (a well know application program in openSUSE):
/etc/zypp/zypp.conf
ZYpp configuration file affecting all libzypp based applications. See the comments in the file for desciption of configurable properties. Many locations of files and directories listed in this section are configurable via zypp.conf. The location for this file itself can be redefined only by setting $ZYPP_CONF in the environment.
And many, may more. Thus I doubt the “something completely out of character”.
In any case, the OP is just following the documentation of his application.
=================
To the OP
I hope you understand how process environment variables work. They are only inherited by the child processes of a process. Thus, for the CLI, when they are set in /etc/profile (if they are for the benifit of all users) or ~/.profile (if they are set and used by a particular user), they are in the shell process and thus available to all processes started from that CLI session (specially login sessions).
For bash, you can also set them in .bashrc. But mind when the one or the other is used (from man bash):
INVOCATION
A login shell is one whose first character of argument zero is a -, or one started with the --login option.
An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option. PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to test this state.
The following paragraphs describe how bash executes its startup files. If any of the files exist but cannot be read, bash reports an error. Tildes are expanded in file names as described below under Tilde Expansion in the EXPANSION section.
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.
When a login shell exits, bash reads and executes commands from the file ~/.bash_logout, if it exists.
When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc then ~/.bashrc when those files exist and are readable. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc.
In a GUI session this might be different. It depends if your DE setup uses e.g. /etc/profile and .profile. I doubt a GUI login will ever look at the specific bashrc or any other shell specific files there may exist for the many shells there are (c-shell, ksh, tsh, …)
