We are not expecting large QCs showing up out of nowhere, breaking sec256k1 keys in few seconds.
That's not a reasonable expectation, when you consider the range of adversaries
Yes, it is. It is how we do our job in technology fields: We study trends and speculate developments then decide. We don't take fiction about a monster that suddenly shows up with super-power, as being serious.
Hashed public keys are safe in such a transient phase and what I absolutely don't understand is why we should include a proposal about public keys being exposed for an eternity waiting for their turn to be destroyed by any innovation or technology that shows up?
That depends massively on how long this transient phase lasts.
It will be long enough: When a technology is in its infancy, i.e. it is not scalable, doubling the speed needs quadratic or higher costs, QC is in such a phase, it is definitively not scalable right now.
If a breakthrough happens in the future and scalable QC technology becomes available, it won't be commercialized for a long time because of governments and military and corporates who need it for their devious plans. It would be very unlikely to be used against the day to day bitcoin transactions. It is also worth mentioning that scalable technology needs time to mature. We are talking about a few years for the least, to be very paranoid.
The safest thing to do is as suggested in the stackexchange article: soft fork to prevent ECDSA transfers, but invoke zero knowledge proofs of BIP32 seeds to indirectly spend them to QC resistant keys.
You need a non-Interactive zero-knowledge proof protocol which is not a piece of cake, it is complicated and both time and space consuming. I don't think it will be ever used in a performance-hungry system like bitcoin. Forget about it.
maybe if you find this so compelling, you could start working on the zero-knowledge proofs to spend ECDSA outputs to QC resistant keys? Like, today for instance? (you'll be busy a while hopefully

) Won't your super coin (or is it a Bitcoin fork, I forget) need it, or will you stick with hashed public keys? We don't want to hold you back, off you go...
Why should you show your trolling face once a week to me?

For my line of research, the main challenge, regarding this issue, is a time&space efficient QC resistant signature algorithm which is an open problem for the whole cryptography community. Although I don't think it would be a wise decision for me to focus on such an algorithm, I wouldn't hesitate to take part and implement it in my proposal, at any point that we might have become close enough to a consensus about a superior algorithm.