I think the two models you propose represent very different things.
A single table keyed on (A,B,C) represents that this unique combination is valid / has data attached to it. Looking up a row and interpreting any data based on A and B only would be an error. If you can predict the valid values of C based on A and B, then it is not part of the key; if there's only one valid C for each A and B, it's just a data column.
Three tables (A,B), (A,C), and (B,C) model a set of separate relationships. Looking up a row based on A and B only is possible and fully supported. What's more, normalisation rules say that these relationships should be independent - the existence of rows in (A,B) and (A,C) should not predict a row in (B,C), otherwise that row is duplicated data.
Other variations are possible, such as a table mapping A to B, with surrogate key AB, and a dependent table listing the relationship of those pairs to C (AB,C); or even a table mapping AB pairs to BC pairs.
There will be different scenarios where different things make sense. Can there ever be an A with a B and not a C? Would the same A always have the same B but different Cs? Does the relationship between B and C have a meaning outside the relationship of either of them to A?
From the additional info edited into the question, you might model the following relationships:
- thing-A has feature-B, giving thing-feature-AB (foreign keys A,B; primary key AB)
- feature-B has option-C, giving feature-option-BC (foreign keys B,C; primary key BC)
- thing-feature-AB has feature-option-BC, giving price X (foreign keys AB, BC)
Note that here we have created additional entities, which might have their own information: I've listed the price as a likely output of the third table, but a thing-feature-AB might have restrictions on when that feature is available; a feature-option-BC might have additional description about how the option applies in that context; etc. These would be either columns, or further tables with foreign keys, such as thing-feature-restrictions with foreign key AB.