This presents as a bit of an unintentional strawman against demonstrating any kind of coding during an interview process. Live coding, if earnestly used only as a filter, does not inherently need to focus on speed or performance. It doesn't have to be a hard "galaxy-brain" problem. It doesn't have to have any tricks to it. It can literally be a simple task that one would expect any working software developer to be able to complete without too much fuss.

Whether this is actually the case comes down to the hiring manager.

If the hiring manager decides to optimize for performance in the coding interview then yes everything said here is true. They will typically hire people who can perform well and fast at simple coding test type problems above other any other desirable attributes.

If however, they simply evaluate the ability to work through (at any reasonable pace) a fairly trivial coding task, but make the hiring decision on bulk of the rest of the interview, then it shouldn't be a problem.

The problem is most hiring managers have not been selected for their ability, or even trained, in interviewing. A coding test is easy to set up (or copy from somewhere), administer and evaluate. It is often literally the least they could do.

What this post describes is simply hiring managers who lack interviewing skills. Personally, I would probably want to avoid reporting to such a person.