Dependency configuration structure may require knowledge that a loose coupling is not fully aware of. This means that we spend more engineering cycles maintaining standard structures that could just as easily be maintained centrally and merely utilized by the loosely coupled bundles.
If the "global function" is defined in a specific bundle and only relates to the operations of that bundle, which is versioned separately as a dependency then there is no violation of the loose coupling of dependencies, since the DI to be used wouldn't be present otherwise.
This is one of those cases where the framing of the argument matters. A non-complex static function cannot operate in isolations and only functions in the confides it was intended to be used, thus limiting the scope of the "global" to be no more than specific designated use cases.
Overly dogmatic approaches to 100% test coverage and testing all executed lines of code can lead to brittle tests that don't inform you of anything valuable outside of the fact that your test itself is broken. This can lead to developers not taking tests seriously.
The only cases in which the test will fail are when the outside code is updated and the expectations in the test were not. This results in test failures that don't actually indicate that anything is wrong and wastes engineering time to update and maintain.