If they consume similar resources I'd almost always opt for the simplest one to understand.
In cases where the simpler one is less efficient, I might still use it if the task didn't require absolute optimization.
That's not a good reason to reject a candidate, even if there might be other good reasons in this case.
However, the interviewer didn't simply insist the query does not do what was asked (when it did indeed return the correct results).
Instead, the interviewer actually insisted it was an invalid query which would not run at all.
I'm not saying this is a good process or that it's fair, but it is the reality right now. You still get OK results and it's far faster and cheaper.
If you are interviewing someone and they solve the problem you ask, and then you don't give them some sort of guidance or constraints to meet your "correct" guidelines, then you aren't doing a good and fair interview.
And as you mentioned, you can also distinct on the window function. This is not an inefficient operation in Redshift.
Also I fundamentally disagree with your premise. One result set is equivalent to another, and as long as you aren't using unnecessary nested loop joins or such, there are a dozen ways to solve a query.
In another interview at a similarly-competitive company to AWS , I was asked to do some work on orders and orderdetail tables to find all customers where the aggregate total of their orders from 2005 were greater than that of their orders from 2007. I did it using a couple of `sum(case when extract(year from datecol) = 200x then order_amount end)` statements.
The interviewer told me the question was intended to test whether the applicant was able to do a self-join but they were impressed with my alternative solution. That is the proper way to test SQL, not to say someone "did the query the wrong way"