CTOR hierarchy in this case refers to a rigid structure in which you are not allowed to have any circular dependencies. E.g.: If UserService and AccountService eventually evolve into needing to talk to each other, you can wind up in this situation. Most would argue you should refactor both services, create a 3rd service or slam the 2 together into 1. I argue that both have independent persistence layers and it makes a lot of sense from a business perspective to have these modeled separately.
So, the implication is that IServiceProvider is a way to "cheat" the system by not requiring you perform an impossible circular CTOR setup where UserService requires AccountService and vice versa. DI cannot resolve dependencies which require each other. In terms of actual harms, I do not really think there are any substantial ones to note. This is technically reflection but only slightly and I haven't been able to notice any performance impact, but we don't do IServiceProvider lookups in tight loops either.
So, the implication is that IServiceProvider is a way to "cheat" the system by not requiring you perform an impossible circular CTOR setup where UserService requires AccountService and vice versa. DI cannot resolve dependencies which require each other. In terms of actual harms, I do not really think there are any substantial ones to note. This is technically reflection but only slightly and I haven't been able to notice any performance impact, but we don't do IServiceProvider lookups in tight loops either.