I have never encountered a situation where high comprehensibility was viewed as a negative. Can you give an example of when this might be the case?

When looking at it from a business perspective, comprehensibility only makes sense to a certain degree. It often takes a lot of time to get to a certain degree of quality, which could otherwise be used elsewhere.

I think that part fits with the "nice to have", and the "small code base size" is sometimes viewed as either a nice to have or a negative. It's reasonable to abbreviate it this way instead of saying "people viewing a high comprehensibility as a nice-to-have or small code base size as a nice-to-have or a negative".

Well, they never phrase it that way. Instead they see its opposites, complexity and mystery, as positives. E.g., the complicated, innovative new architecture that turns out to be a boat anchor. Or the people who, intentionally or not, write themselves 200kloc of job security and treat the resultant incomprehensibility as a byproduct of their genius. Rather than their failure to apply that genius to making things clear and approachable to others.

It's usually just not a priority. Making it your top or one of your top priorities is rare.

It might be seen as a waste of time.