Which has absolutely nothing to do with my point.
Nobody is arguing whether you should keep your codebase readable. The question is whether that should be prioritized over correctness.
The situation is: your codebase is already as readable as possible, but you've now discovered a problem for which you're failing to come up with a readable solutions. [1] I'm saying, when that happens, you need to be willing to just bite the darn bullet and go with the ugly-but-correct solution so that your customers actually get their problems addressed. Don't just leave it as a dangling "known issue" or leave some silly hack in there just to "keep the code readable". Your customers/users won't applaud you for keeping your buggy codebase readable. Of course you can feel free to make a ticket or leave a TODO in case you're hitting a blind spot or someone better comes along in the future. But for now, solve the dang problem first, because your customer isn't paying you for source code, but for the end product. (Well, unless your customer is paying you to ship source code to them, in which case you should ignore me.)
[1] To be crystal clear (and hopefully avoid more strawmen...), I'm saying you (and your team/company/etc. as applicable) need to actually do your best to implement a readable solution first, and THEN fall back to an unreadable one if you fail to do that despite your bona-fide attempts. For some reason (maybe it makes it easier to argue over the internet? maybe it's just more convenient?) people love to strawman "you should prioritize correctness over readability" as "you should go with the first solution you like whether or not it's ugly; feel free to leave a TODO for some poor soul to polish it later". Which has emphatically never been what I've been saying, but that's what people appear to respond to.