Шаблон Data Dependency

А всего-то надо было в Rank передавать все команды всегда.

Это оправдано по производительности, т.к. разрешение зависимостей делается единожды, а параметры передаются для каждой уникальной пары из ранжировщика и команды.
Это оправдано архитектурно, т.к. компоненты использующие DD могут использовать друг друга, а, следовательно, ранжировщики смогут получить доступ не только к данным, зарегистрированным в текушем контексте, но и к данным зарегистрированным во внешнем контексте по отношению к TopBuilder.

Хотела бы вставить свои 5 копеек.

Опыт показывает, что создавать поставщиков по примеру:

public interface IRankerProvider
    {
        IEnumerable<IRanker> GetRankers();
    }

нет ни какой необходимости при использовании DI.
На много проще управляться с агрегатами и композиторами, имея в системе всегда только один оценщик.

Для демонстрации примера возьму ваш

  public interface IRanker
    {
        int Rank(ITeam team);
    }

И композитор будет вот такой:

public class RangerComposition : IRanker
{
   private IRanger[] rangers;

   public RangerComposition(IRanger[] rangers)
   {
       this.rangers = rangers;
   }

   pubic int Rank(ITeam team)
   {
        // Только для примера
        return _rangers.First().Rank(team);
   }
}

Тем самым система упрощается в понимании и тестировании и избавляет от желания использовать приведение типов для нахождения нужно компонента. Создаёт возможность за один раз использовать больше чем один оценщик итд.

Моим примером я избавила вас как минимум от двух не нужных компонентов:
закрытого и не тестируемого BuilerWorker а так же от IRankerProvider

Возможно вы не знаете одну из особенностей Unity контейтера:

container.RegisterType<IModule, ModuleCompiosition>(); //default
container.RegisterType<IModule, One>("One");
container.RegisterType<IModule, Two>("Two");
container.RegisterType<IModule, Three>("Two");

Дак вот, если предствить, что конструктор ModuleCompiosition принимает массив IModule[] то при попытке сделать:

container.Resolve<IModule>(); // без указания имени регистрации

То, Unity подсунет туда все остальные IModule которые были указаны поимённо при регистрации.

НО, в целом у вас какая-то извращённая реализация паттерна «Стратегия».

Ужасное решение. Интерфейсы на то и придуманы, чтобы показывать контракт.
Когда неявно подразумевается, что в контейнере должны лежать данные для вызова метода, это крайне неочевидно для реализующего интерфейс человека.

Как костыль для существующей системы, которую лень рефакторить, хм, может и сойдёт, но проектировать так нельзя.