When contemplating return on complexity in an environment where there is no good mapping from "returns" to finances, the concept remains valid. This holds true for many if not most group decisions made after the functional requirements for a product have been agreed upon.
It is, however, necessary to redefine the measure of both benefits and costs of complexity.
From a user experience perspective, what is the cost of adding a small amount of complexity? Let's say that the complexity is an extra step in a setup process or an extra interaction in a voice dialog. If we arbitrarily define a scale from 1 to 10 where 1 is "no cost to the user", 10 is "the user becomes likely to stop using product/fail task/??", we can map situations to the scale with reasonable repeatability.
You'll need to develop standard definitions for certain points along the scale - much like your bug severity definitions - to create some consistency amongst your business and development teams. A 2, for example, might be "takes the user a little extra time but creates no extra confusion or risk", whereas a 3 or higher would be reserved for changes that can introduce risk, confusion, or aversion for the user. By the way, a rating less than 1 indicates that the experience would be simpler for the user, and thus you are running your decision the wrong way - we are assuming that simpler is better.
Similarly, we can define the benefits resulting from complexity on an equivalent scale. A 1 would indicate no benefit; a 10 would indicate "there exists some measurable financial benefit". The reason for selecting that as a 10 is that a decision that results in measurable financial benefit can be mapped to financial costs and benefits, and the argument about whether to add the feature or complexity involves a different set of people. This "micro decision" ROC metric is intended for situations after the functional requirements have been finalized.
The final piece of the puzzle is one of company strategy. For some companies, if ROC > 1, the complexity will be added. For companies who wish their brand to have more to do with ease of use or simplicity, an ROC > 3 might be required. However, any ROC < 1, for any company, should be avoided.
In most cases, the ROC calculation will be unnecessary - a simple discussion of benefits and costs will be appropriate. The mere addressing of the costs of complexity causes many otherwise "obvious" decisions to add complexity to be discarded.