I think you’re right that if you’ve already decided what the outcome will be then it’s not worth your time but also think it severely undermines the value of your opinion for others.
I have a feeling it's a bit like being color blind. It doesn't help how much people try to explain just how different red and green look if I'm red-green color blind.
Ever since I got somewhat proficient at programming, I've been able to take a quick glance at some non-terse code with descriptive identifiers and get a feeling for what it's doing. Often very accurately, which makes it easy to mentally filter the code into what I need to focus on and what's irrelevant to the task at hand.
But if people write very terse code, this goes down rapidly. I have to spend a lot of time scanning for important symbols, unpacking what's going etc. When they stuff everything on as few lines as possible and use single-letter, non-descriptive identifiers it gets significantly harder to read for me. Now I really have to study the code, and remembering what things do gets harder due to non-descriptive names.
I've worked on a fair bit of really terse code, and I find it just doesn't allow me to be as productive as I am with less terse code.
This is why I doubt that learning k will completely change that, and given that I have very limited time and capacity for fun things like learning new languages, I was curious if there was something more approachable for me.
I think very few would argue that this style of coding doesn’t demand more of the developer, but the thinking is that the focus it demands is appropriate. Programs are written for running, ideally accurately. Without focus you can’t be 100% sure the code you glossed over wasn’t important. Hopefully though this style allows you to spend your valuable attention on the bits that matter.