For runtime reconfiguration of anything that impacts the state of running processes, it is expected that you would use the config_change handler in the application callback module - when this is invoked it ensures that you can execute configuration changes in a predictable and coordinated fashion.
The problem with just hitting Application.get_env/3 everywhere when it comes to reconfiguration, is that you can’t guarantee anything about when you will fetch values from there. For example, you may fetch two values from Application.get_env/3 in the same function, both of which depend or are related to each other in some way - if configuration changes are being applied while that function is executing, you may get a mix of old and new values, which result in odd or unexpected behavior. By instead coordinating the config changes with the processes which need to change, you get predictable results, and can make sure that trickier config changes, such as changing the port a socket is listening on, etc., are performed correctly.
For something like your Logger example, yes, fetching directly from the application env may work just fine, and may even be preferable if it is something you need to do often - but cases where you can safely reconfigure things on the fly like that without any guarantees are less common, I think, than cases where the configuration has impacts on the state of a process, or many processes, or may even change the behavior of the application entirely (such as changing the implementation module for some behavior).
You don’t have to implement config change handling in every process, you implement it in the application callback module, and orchestrate the configuration changes from there. This may mean talking to processes when they need to perform some work to reconfigure themselves, it may mean starting new children under a supervisor and terminating old ones, or it may not require any implementation work at all. For convenience, it may make sense to have config_change functions defined at the supervisor or process level, and have the application config_change function call those functions, but it’s certainly not required.
Yes, I’m not arguing that you should never use Application.get_env/3, there are still times where that is useful or convenient - but you should prefer configuration by parameters where possible, especially in libraries, because you don’t know if Application.get_env is going to be convenient for your users. This is a huge part of why runtime configuration has been such an issue with releases historically - libraries leaned too heavily on application env, rather than on designing APIs which are configurable, and it made it very difficult to configure them (naturally), as a result. Using application env is painful even outside of releases for similar reasons - it’s just another form of global state, which means that if you need to change that state, or run multiple configurations side-by-side, you can’t.
