The problem is that a "C" is often introduced when it is unnecessary, and it can cause unnecessary new codepaths, due to how codepaths are sliced up per the abstraction. In the case of A -> B, it is possible that instead of requiring A|C -> B, A can be expanded, and 99% of the function (the ->) can remain the same, but you've done O(1) work for adding the new requirement, which otherwise would've been done by writing an entirely new codepath, C -> B.
This can occur when, for example, types are defined to be categorically coupled with sets of behaviors/effects. Introducing a new behavior/effect, perhaps a slight mutation of an existing example, requires fitting these new effects into the existing abstraction, which now means introducing a new type, which also means introducing new codepaths in all cases where other type variants had separate codepaths.
A simple example is a traditional OOP-style widget class hierarchy, or the discriminated union equivalent. You have class Widget, and class Button, Slider, LineEdit, Checkbox, RadioButton, all extend Widget, etc. - Widget has virtual functons for responding to events. For example, OnClick: Button|Slider|LineEdit|Checkbox|RadioButton -> Result. Now if I want a slightly different kind of button, which requires some features like a Slider, other features like a Checkbox, other features like a LineEdit, and so on, I must either fit that into the hierarchy somehow, or I must introduce a new subtype. In practice, what I find is that the hierarchy is entirely unnecessary to begin with - it is much simpler to assume each widget can cross-cut across the set of features in arbitrary ways, rather than enforcing a hierarchical shape. Thus, you have one homogeneous type at the bottom, which at the limit can have *all features* turned on, and in practice you just select a subset.