This seems like a false sense of security at best to me.
If a CRQC appears, I don’t see how BTC can retain any value at all, if EC spending is not disabled. This is not an argument in favor of freezing; it is pointing out that we can ignore potential timelines/blockchain forks in which (crqc exists AND NOT ec is disabled). A chain in which millions of BTC are believed to be stealable fails at its primary function. In such, value is lost anyway, so nothing being discussed here matters.
Thus, for the point of discussion, we can treat any CRQC-having timeline as being one in which EC is disabled, regardless of how, when, why, or in which fork that happens. It doesn’t need to be discussed now even, but we can still assume it happens somehow in such timelines, because the alternative is simply not relevant.
If EC is disabled, P2QRH being available independently of PQC locks seems irrelevant to me, because nobody should be using it without PQC locks. For mixed EC-or-PQC spending conditions, P2TR is strictly better in functionality, privacy, and (typically) cost. For pure-PQC spending conditions, something like P2QRH may be relevant, but there is no way to judge that without an actual PQC scheme (e.g., maybe the scheme supports taproot-like tweaking).
And I could see relevance to P2QRH if it disabled EC from the get-go, because that would mean an observably-PQC output type, which makes it susceptible to policies/consensus rules that mandate at some point that PQC outputs must be used. I don’t think that’s a particularly attractive idea (I feel outputs should reveal as little as possible), but this is what I assumed P2QRH was aiming for when I saw the name and your ML post. However, this appears to not be at all what BIP360 is aiming to achieve, and thus, I fail to see the point.