To be clear, a collision attacks is where an attacker can find any 2 inputs to the hash function which result in the same hash. Typically these are random inputs and it requires ~2^80 hashes. The important thing is that it is
not finding another input which has a particular hash - that would be a preimage attack, and in the case of finding a
different input, a second preimage attack. Preimage attacks require 2^160 hashes for hash160.
Will it be possible to eventually either a) strip hash160 from old P2PKH addresses,
No, the address is an encoding of the hash itself and hashes cannot be reversed.
or b) completely disable spending from them after an extended waiting time in the future?
Yes, but it is probably not necessary. In the context of P2PKHn addresses, I think a collision attack is just kind of bad. What would be really bad is a second preimage attack as that would mean finding another keypair with the same hash. It's a different story for P2SH, which I will explain below.
From a price point of view, even attacks carried out on dormant addresses are enough for media to write up negative stuff about the incident which'll reduce investor confidence (which means the price tanks) and user adoption despite the whole rest of the network using P2WPKH and P2WSH.
A collision attack is unlikely to affect existing addresses as their current use is nowhere near the 2^80 upper bound for brute force collision attacks.
Trying to find a collision with any address in use might seem like a collision attack, but because the number of addresses to search is so much smaller than 2^80, it's more akin to a (second) preimage attack.
Collision attacks become problematic when someone is able to convince someone to accept coins with a particular address. This is unlikely for P2PKH, but could be a problem for P2SH. Suppose you and I are doing business together and we want to have some coins sent to a multisig address. I generate a keypair, you generate a keypair, and we make a multisig script. This gets hashed with hash160 and becomes a P2SH address. Now suppose that, in secret, I had actually generated tons of key pairs, and in parallel, constructed a different P2SH script where I am the sole signer. By generating new scripts with random keypairs, if I make 2^80 of them, I should be able to create two scripts which have a hash160 collision. One script will be the multisig between you and me, and that's what I give you. The other script is just me as the signer. Now when a payment is made to the supposed multisig address, I can take those coins because I have a script where I am the only signer and its hash matches that of the output.
This is the danger of a hash160 collision. It has to do with P2SH and how a malicious party could produce a colliding script with different spending conditions. Because it is more concerning for P2SH, P2WSH and Taproot both use SHA256 (or hash256) which is expected to need 2^128 hashes to produce a collision.
