If you're colourblind and two different parts of the interface look too similar to you, then please, raise a bug.
For certain products, this approach makes sense. Generally, this approach works for "any software where more adoption means a better experience for an individual user". Examples: a messaging app, anything with its own format (like a word processor), because it makes sharing easier, or anything which I need to work with as part of a team (version control).
This is not that. File listing programs are local and isolated. My experience using some file listing program does not improve if more people use the one that I am using. In this case, it makes more sense to have exa or ls or whatever be the software that addresses 99% of use cases for the average user. Then, for the portions of the population with particular needs, you make software that is particularly tooled towards them.I am not colorblind, so having support for colorblindness just makes software more bloated.
tl;dr - I agree with your sentiment when it comes to programs that need/want "universality". This is not one of those programs and doesn't need to be.
What I've seen people doing is saying that there's no line at all: every feature needs to have its cost justified, every type of user scrutinised to make sure they're not dragging the product down. This is expected behaivour for startups (launch to a limited market first) and big companies (where you need to justify every cost) so I'm not surprised to have encountered it here.
For colourblindness in particular, though, I still think there has to be a way for the default colour scheme to be colourblind-friendly without the experience for everyone else suffering as a result.