I mostly avoid default-returning from modules TBH. I like the fact that we can forced the consumed to use a named exported value/object from the module.

Convining co-workers can be tricky, at least for this state of mind. I'll explain them how difficult things turn out to be if not done this way. One difficult convincing scenario would be trying to implement TDD(Test Driven Development).

You could start by stating how a software solution is better off by not being attached to implementations but to abstractions. If a module/function/service or whatever layer representation you would have is tied to a certain implementation, it's going to be a mess when you want to change it due to business requirements, due to the implementation not being enough, etc...

Let's say that you installed a library and you are directy using it in many layers and modules of your application, and then you find out that it has a security breach... You'll need to every place you're using it in order to change for a new one, and will have to modify big parts of your codebase to comply to the new library API. This is just one example...

Another thing I'll state is how difficult it becomes to test that, you'll require to do some "magic" in order to mock dependencies... What if you want to perform a test without calling the real database, or using a fake mailer, etc...? That easily gets messy, IMO.

In conclusion, what is important when trying to convince is to be able to demonstrate how messed up things are and how they would improve using whatever approach you are suggesting. For this case, being able to provide dependencies to the caller gives you total control on how to do things and makes testing easier in general, which is REALLY important.

I hope I was clear enough in my response. Please feel free to keep asking questions. I'm here to help.

Also, I don't hold any absolute truth, all my comments are based on previous experience and reads through out my young career, so maybe some other people might feel different around all of this.