I agree.
I love how OTP primitives make complex state management explicit and easy to follow without dictating how the project needs to be structured. Dependencies starting their own supervision trees could be more convenient, but as soon as I need to debug something or want to implement a usage pattern the library designer didn’t foresee, things could get a lot less convenient. I can understand the desire to make a library super easy to use for the “common” cases, but that usually comes at the expense of making it more cumbersome to use in other scenarios. And most real-world problems seem to fall into the “other” category in my experience.
I also prefer it when I can put config into the initial state in the child spec as opposed to having a 10k line config.exs file. It keeps the process orchestration and configuration in one place. And if I did want to have the dependency’s config in the config.exs, I could still add a config key for it myself and just call Application.fetch_env!/2 in the child spec. 
