Interviews (by design!) simulate intense interaction between the interviewer and the interviewee, similar to a workplace situation when trying to solve a problem. That setup is not objective.

The result, even just the code itself, is also not judged on a binary yes/no scale, which again leaves a lot of room for opinions and bias to muddy the water.

I've done hundreds of engineering interviews. Conducting objective interviews is very hard. Anybody thinking they are objective either has never done interviews or is fooling themselves.

It absolutely plays into it.

If a programming exercise is subjective, from what perspective is it subjective in bias of? Likely the author's, who's bias will be derived somewhat from their race, gender, sexuality, socio-economic class, background, peer group, etc.

Code is correct if it works. But plenty of "working" solutions will be rejected as being "incorrect" based on current trends, internalized philosophy, preferred approach, etc. etc.

As someone who hires engineers, it is difficult if not impossible to separate personal bias and preference from an evaluation.

You absolutely have, because in the real world "correct" isn't a cleanly defined objective target. Humans decide if your code was well-written enough or you used an appropriate data structure, and humans can be pretty solidly relied upon to blunder into all manners of cognitive shortcuts and biases.

You've never seen code implementing a form to gather names?

I've never seen that specific test (that'd be a useless test), but I get your point. "Here's a thing to do, do it."

But there's a billion ways to write that code. Which ones will the evaluator prefer and/or reject? That's where subjective opinion comes in.