I don't really have any substantial grounds to nack the change.
From what I recall, this code path was mainly used to unwind through glibc frames that don't (didn't?) have unwind info. IIRC virtually every stack had one or two such frames at the end of the trace ("top-most frame", or "start" of the stack, at least for the main thread).
I vaguely recall there were also common enough anomalies - mostly unwinds starting off with bad unwind info, e.g. from an async signal, reading stack wrong and going into random junk - that would cause stuck infinite traces with zero-size frames, with unwinder making no progress. I'm not entirely sure if it's possible to fully define "progress", but at least one of RIP or RSP/CFA should be changing? Zero size frame (no CFA movement) where the next unw_step will end up using the same RIP would be bad news, as would be a short cycle of RIP addresses with no CFA change.
Other than that, my only concern would be whether the fast trace needs to, or can be, taught to deal with such frames. As long as they don't happen in anything performance sensitive, it wouldn't matter - the fast trace would fall on the slow one, and everybody would be fine.
I'm not currently actively involved with the unwinding related stuff, and am not able to brush up on the details right now - and could easily be wrong. So please go ahead if it looks ok to you, maybe as long as we protect against zero progress frames? Also, I don't have any recent data on how likely missing / bad unwind data is these days for the general (non-jit) case.