Being on the interviewer side of the table more than the interviewee side, I like to think that almost all complaints about the terrible way "the industry" interviews are still valid, but that for the people I've interviewed, even if they share many of the complaints, I like to think most of them also think "well except with that guy, that wasn't so bad." Even though I've always been frustrated about not being able to really try the interview styles I want to try and have to somewhat conform to a terrible mold.

I may be kidding myself but I do think having an interviewer who gives a damn and recognizes "the industry" standard sucks is key. I disagree with you in that I do actually care about (aspects of) the solution, but that's not all I care about. Interviewers disagree with each other all the time on better ways to interview, but there's a whole class of interviewers who just don't care and will perform whatever HR or their manager or some other interviewer tells them to do. I think these also get the most complaints from interviewees. The possible exception is if you actually have a robust work-sample test with objective metrics.

Whatever the case interviewers should strive to make sure interviewees understand the parameters of the interview rather than hope the interviewees can read minds. Not all interviewers believe "it's a conversation" and some will penalize you if you ask questions, some will penalize you if you don't ask questions... As an interviewee it's an adversarial experience and without any indication from the interviewer to set expectations to the contrary it's no wonder interviewees will be guarded or choke or whatever else.

I don't like to give straight-up algorithm problems like "implement this data structure and one or two common client use cases for testing". But interviewees should prepare for it, even if they're not fresh grads, because "the industry" sucks at interviewing. What if you're forced to give an algorithm-type problem by someone higher up? I think interviewers who give a damn even a little can make this significantly better than the default archetype characterized by complaints.

For the interview I got hired from most recently I had the fortune of having interviewers who weren't robotic, they said "use any language you like, can you implement a stack?" and I typed "In python, stack = []". They had me elaborate a little, then we talked a bit about Python, I mentioned it can also be a queue if they wanted as the built-in array is quite flexible, then they had me do some other stuff. Having brainfarted "implement a stack with plain native arrays holding ints in Java (and the clever implementation of a stack with memory by self-referencing an object of itself)" in a prior interview I'm aware that even basic stuff can end up taking many minutes of time, I'm sure my interviewers thought that most candidates would take a certain number of minutes for the stack question, but they were dynamic and could ask other things rather than waste both our time. Meanwhile another interviewer I worked with did an interview where he gave someone a "standard" "reverse this string" problem and the person responded in Python with something like "str[::-1]" or similarly concise, but coworker made them do it again in the "standard" way. No, instead that should have been an indication to move on to a more interesting problem.

If I were made to give a linked list problem and someone responded with a good old (cons) from 1959 we'd be done. I wouldn't make them (defstruct) and (defun) their poor equivalent but instead move on to a more interesting algorithm problem that can use linked lists as a building block, e.g. something involving a BFS or DFS (and even though I like iterative versions of such they might very well hit me with a recursive solution, and that'd be fine). Back to the twitter thread I don't think the reason the linked list has endured has anything to do with lower power computers back in the day, since it was a common abstraction on much weaker hardware and came built-in with a variety of popular languages long predating C and long after C.