only people with P2PK addresses should definitely move all their coins
I disagree. If P2PK is unsafe, then many other things also are. In general, finding serious weaknesses in P2PK would render everything under P2TR as "unsafe", as it is under P2PK, just because by reaching the private key, the whole TapScript can be skipped by any attacker, who will just make a Schnorr signature, and then will unconditionally send coins to any destination. So, if you think, that people should move coins from P2PK to P2TR, then I have bad news: it won't make coins "safer" than they currently are.
Also, if you think, that hashing is a good protection, then again: there are more bad news. If someone is using 160-bit hash, to protect 256-bit public key, then there are around 2^96 matching public keys, which would allow sweeping everything. Currently, secp256k1 is safe, and hash functions are safe. Some people assume, that secp256k1 will be broken faster, but it doesn't have to be the case. And if someone will have enough power, to compute things 2^128 times, then the same person will also probably have enough power, to compute it 2^80 times, reach some collisions, and raise a panic.
If we believe, that the famous puzzle, based on N-bit public key, is honest, then we can see, that 71-bit hashed key is in progress, and 135-bit public key is also waiting for solution. Which means, that going from 71-bit hash to around 80-bit hashes may take less time, than going from 135-bit public keys, up to 256-bit ones (the puzzle ends on 160-bit, but range 161-256 should probably be recreated, and based on public keys, instead of hashes, if we would want to also trace that progress).
Current miners can produce double SHA-256 hashes with around 80 leading zero bits, every 10 minutes. I guess if there would be enough incentive, someone could produce a 160-bit address collision, just to raise some panic. Of course, finding a collision won't immediately render things under 160-bit hashes unsafe. But it will question the migration from for example P2PK to P2PKH. And in case of P2SH, it would indirectly provide TapScript features into P2SH, because by having a collision, users could reveal one version, or the other, and use "<pubkey> OP_CHECKSIG", and 2-of-2 multisig, by sending coins to the same, collided address.
More about it:
You can't use a coin without exposing its pubkey.
So, if someone thinks, that P2PK, P2TR, or any other address type is "unsafe", then there is a good question: what is the alternative? And if it is hashed, like P2PKH, P2SH, P2WPKH, or P2WSH, then still: does it use OP_CHECKSIG anywhere? Because if it does, then it is not "safer". And if it doesn't, then how public key cryptography is handled?
Not doing so is a mistake and risky to both the user and the network.
As long as we have OP_CHECKSIG, or its equivalent in use, practically everywhere, moving coins between different address types, won't change that much in practice. Because to use a coin in a safe way, you need to make a signature. And to do that, you have to touch secp256k1. As long as it is the case, there is no reason to play ping-pong between different address types, and weaken your privacy.
@stwenhao I summon thee.
Could you tell us all the methods that are provable state of "coin is lost"?
Only if the Script evaluates to false, or equivalent (for example if it is marked as invalid).
OP_FALSE as a raw script is unspendable. But wrapped in P2SH, P2WSH, or P2TR, it can be potentially moved, by reaching hash function collision, or by breaking the private key, and skipping the whole TapScript.
OP_RETURN is unspendable, if executed. You can however spend coins from "OP_IF OP_RETURN OP_ENDIF" with just "OP_TRUE OP_FALSE". Maybe some implementations can be forked with tricks like that, if they will mark unexecuted OP_RETURNs as unspendable.
Many unspendable scripts are described here:
https://en.bitcoin.it/wiki/ScriptFor example: OP_VERNOTIF will automatically mark transaction as invalid, if it is present as a raw script. However, if you will wrap it in a TapScript, then it will be spendable by anyone, because of OP_SUCCESS.
In general, for P2TR, only addresses with invalid x-value coordinates of secp256k1 are unspendable. Everything else can be spent by key, if you can reach it somehow.