Overusing @Global() causes hidden coupling, harder testing, potential naming collisions, and refactoring friction. Consumers silently depend on global providers without declaring it, making it impossible to read a module's dependencies from its imports array alone.
Hidden coupling — consumers silently depend on global providers without declaring it in their imports.
Harder testing — unit tests must provide global providers even when the class under test doesn't obviously need them.
Naming collisions — two global modules exporting a provider under the same token silently shadow each other.
Refactoring friction — moving a global module to a different registration point causes hard-to-debug resolution errors.
Reduced modularity — feature modules can no longer be ported to other apps without also porting all global modules.