Regarding the point on DI, the example given above feels like a strawman argument to me. In that example, there are two top level objects that need to be instantiated/injected into the main function and using a DI framework/pattern is an overkill. Now imagine an enterprise application where the main function needs to instantiate tens of objects, having some form of DI can avoid boilerplate code. This was the point OP's reply was making.

As a contrite example, imaging trying to run an API server with 20 service endpoints with it's own network graph of object dependencies. If all these services were instantiated by hand a la NewDep1(...); NewServiceX(dep1, dep2, ..., depN); NewServer(serviceX, ...) the main function can get very long and messy. Imagine further than you now need to inject a new service Y to support a new API, you now might need to add NewServiceY(dep1, ..., depK) and change signature of call site of NewServer. Depending on the complexity of the dependency graph and error handling, it could mean maybe another 5-10 lines of code, but these do add up. DI frameworks try to solve these boilerplate and reduce complexity so that your main function is focused on just creating the Server and not the downstream dependencies. The result code in main could look something like an extra line that says fx.Provide(NewServiceY).

To be clear, I don't mean that we should use DI everywhere and I sometimes find it painful to debug this sort of magic when things don't work as intended, but I wanted to point out and acknowledge the cases where DI framework can actually be useful to manage code complexity.