Could Taproot create larger security risks or even hinder future protocol adjustments re Quantum threats?
This particular response is approximately tripe. Building on Pieter Wullie's comment.


  find an appropriate post-quantum DSA


and


  it might push the the time to make Bitcoin quantum-secure from 5-10 to 10-20 years, as much more research is needed. 


We really know what to do to make Bitcoin Quantum safe, there's been methods for doing hash based cryptography in varying forms since 1979, which predates even Schnorr in 1991. Adding a new signature type to Bitcoin can be done with a soft fork, even though the specifics of how this would work (they would likely be a merkle tree of public keys).

I personally wrote a patch for adding OP_LAMPORTVERIFY as a project while bored on a plane in 2015, other than coming up with something sensible for the formats and desperately trying to convince people not to re-use addresses (for real this time!), it's engineering that can be done on a short international flight.


  With taproot activated, we also need to solve (3). If we solve (1) and (3) together, this may take too long to achieve (2). That's the risk we take by activating taproot now.


The two are basically orthogonal, there's no difference between migrating between outputs stored with taproot and those using raw ECDSA. The existence of taproot doesn't make this any more or less difficult functionally. 

If any quantum computing was a significant threat (ie, wasn't just theoretical or slower than classical computing), we would have a lot more to worry about than just Bitcoin regardless.