Service location is considered an antipattern...
I personally think the only disadvantage of classic DI is big constructors, but big advantage is explicit dependencies without global state.
You are right that you usually don't want to inject a bundle of dependencies when those dependencies aren't all needed. Definitely not just to cut down on constructor size (annoying as it may be).
Injecting such a bundle is reminiscent of a service locator pattern, which is commonly considered to be an antipattern, or at least inferior to direct dependency injection (i.e. injecting the dependency, not the locator).
Context in your question may not exactly be a service locator, it fulfills the same purpose as a service locator. It acts as a bag of dependencies that the consuming class can take dependencies from at will.
...but a unit of work is not.
For example his
Context object may have static variable
repository. [..] it looks like this is some kind of global state and also it may act like magnet object, growing and growing over time.
These context objects often acts as a unit of work, which precisely justifies them being a magnet for all the data access they provide.
A unit of work provides transactional behavior. Transactions can span across multiple repositories (e.g. either I input your user details, addresses, and billing history; or I input nothing at all). That is desired behavior to ensure you don't end up with half-done data entries.
If your consuming code were to handle the repositories separately, it would be both hard and unreadable to figure out exactly when the transaction could be committed or rolled back.
By providing access to the unit of work object itself, the consuming code is able to explicitly cause the transaction to be committed (or rolled back).
By putting the repositories in the unit of work itself (as opposed to separatedly injecting them), you both allow for the use of multiple units of work (= different repository instances, so repositories can't just be injected independent of the unit of work they belong to) and it's made much clearer exactly which repositories are managed by the unit of work (in case your codebase has other persistence stores as well).