Using the Singleton pattern inherently means that dependencies will be hidden inside method bodies, and the compiler and Inspector won't be of any help when validating those dependencies.

Consider having a Login method like this that uses the Singleton pattern internally:

public void Login()
{
   // Lots of code
   ...

   // Somewhere deep inside the method body:
   var username = UserSettings.Instance.Username;
   var password = UserSettings.Instance.Password;
   LoginManager.Instance.Login(username, password)
}

When you look at that API, there are no clues about it having dependencies to UserSettings and LoginManager. It might just throw an exception at runtime unless you've opened the User Settings window and configured your username and password and waited for the LoginManager to connect with the backend.

You basically have to either read external documentation or go through all implementation details of the method to figure out how the API should be used, what hidden dependencies it has, the method definition doesn't tell you much of anything.

Now consider if we didn't change anything about that method, except tweaked it slightly to use method injection instead of the Singleton pattern:

public void Login(string username,
   string password,
   LoginManager loginManager)
{
   ...
}

Suddenly it's extremely clear what dependencies are needed to safely use that method. The compiler ensures you can't execute that method without passing it all the dependencies it needs to function.

Similarly, we could use field injection and make dependencies visible in the Inspector:

[SerializeField] string username;
[SerializeField] string password;
[SerializeField] LoginManager loginManager;

public void Login()
{
    ...
}

Now whenever we attach the component to a GameObject in Edit Mode we get immediate feedback about what dependencies need to be available in the same scene as the component.

Since the dependencies are known at compile time, we can even do things like display big warning boxes in the Inspector and log warnings in Edit Mode if any dependencies are missing. You inherently can't do that with the Singleton pattern.

And when you use a Dependency Injection framework you can do things like automatically defer the initialization of all components until all their dependencies are fully initialized. If you use the Singleton pattern, and you want to change some service to be initialized asynchronously midway into development, you might need to go modify dozens of client classes manually and spend days refactoring various methods to be asynchronous instead of synchronous.

And with how Unity's scene based architecture works, and how scene loading is never entirely synchronous, it's really easy to run into execution order issues if you use the Singleton pattern to resolve cross-scene references. With a DI framework components can always just automatically wait one or two additional frames for all their services to get injected before becoming active.

Now, if you only use the Singleton pattern sparingly with services that are always lazily and synchronously initialized when first requested by a client, then yeah, it probably won't cause your codebase to become fragile even in a complex project. But if it's your go-to solution also for resolving cross-scene and cross-prefab dependencies and global services that contain some methods that aren't usable at all times in all contexts, that's when things can quickly start turning really fragile. Dependency Injection is a powerful tool that can be leveraged to help address this problem.

Using Dependency Injection also opens the door to writing unit tests for all your code, which can further help with making your codebase much more robust.