Ok; so we can derive a Bitcoin address from the private key. The same algorithm is used in both transactions, right? We still don't see the relevant difference.
If an amount is paid to a public key then the public key is shown in the public blockchain for anyone to get/see/use.
A Bitcoin address is the double hashing of the public key. So BitcoinAddress = hash(hash(PublicKey))
So if you pay to a Bitcoin address what is shown publicly in the blockchain is the Bitcoin address not the public key.
Now theoretically to crack a payment to a public key you would need to reverse only the ECDSA, PublicKey -> PrivateKey
But to crack a payment to a Bitcoin address you would need to reverse SHA and RIPEM and ECDSA
BitcoinAddress -> reverse hash -> reverse hash -> get PublicKey -> PrivateKey
So, you can see that since the hashing algorithms are not vulnerable to QC then payments made to Bitcoin addresses are basically not vulnerable to QC.
BUT
If you make a payment from a Bitcoin address to another Bitcoin address and have the change come back to the original address then the public key for the original address is now exposed. So, just do not do that - always send the change back to a brand new address.
Modern deterministic wallets always send the change back to a new address. The new blockchain.info wallet is a deterministic wallet and does this correctly.
However the very popular old blockchain.info wallet (and others like it) always sent the change back to the original address unless you explicitly told it not to so there are a lot of transactions that did expose the public key, those would also be vulnerable to QC attack.