everything goes to physics with you, even though in this case it's about the scalability of hashes. yes, sha256 hashes are steadily becoming more vulnerable, nothing to do with quantum, more to do with the fact that the energy cost of one sha256 hash has been hammered down hard chasing bitcoin blocks.
actually, that's a good reminder why i should consider not using that function in my design. probably should switch it to use a final blake2b or blake3 hash. or keccak. hashes on data are a variable space that only really becomes a problem if the source is very uniform, and small. so, yeah, hashing pubkeys is only one hash of cost. i would think that some kind of modulo expansion would be in order to make it more robust. a non-linearizable, non-parallelizable function is the best, for my money that's the long division. it's impossible to parallelize it or linearize it, it operates in pretty much O(N) time where N is the number of bits. that's also why i use a long division based expansion on the CPU-only hash function i designed back in 2018 for a bitcoin fork. that forces the work cost to become both variable (the length of the result of many expansions is unpredictable, and by design, the total length of data being hashed is very long, so it's pretty much invulnerable even when you have fast processors like modern bitcoin mining ASICs.
a hash function that is not parallelizable would also be a good idea. that rules out blake and sha2/3 as both are designed to be parallelisable.
also, quantum computing is bunk. until they prove they can error corrrect their outputs it's pure fud