Let's step back for a second: You can update a unit price based on a FIELD VALUE. The place where this can happen today is not configuration, it's pricing/commerce - the line editor.

"Product options" should only be thought of as the logical reference to a product that exists entirely within configuration. There is a lookup to product option from a quote line which was created based on selection of a particular product within configuration, but nothing is updated or changed on that option according to what an end-user does in CPQ. Configuration attributes, similarly, are logical references to a field, in this case that exists on the product option object. A configuration attribute value specified in configuration can be used to select or remove a product (product rules) and that value can be written/updated on the resulting quote line (twin field functionality), but until Spring '20 is available the weekend after Valentine's Day, you cannot create a price rule that fires in the configuration context based on a configuration attribute - you can only create one which fires in the line editor context based off an attribute's quote line twin.

Even when the new capability is rolled out, you may still wish not to update unit price within configuration because price rules will continue to be extremely limited in configuration contexts. The reasoning for that was the subject of a long write-up on generalized CPQ best practices in a comment I posted in a different thread. But in general/short, it is beneficial to design simplicity/elegance and performance to separate search + configuration (resulting in a DML operation) and pricing + discounting (resulting in a record update), as opposed to trying to do them both at the same time (trying to select a product and customize its price simultaneously).