Not an expert in such particular details. My first thoughts regarding this additional long secret are: you have to validate it to unlock and you can't place the long secret into the unlock condition, so it must be hashed. Now, is the hash function quantum-resistant? If not, you don't gain security, so it doesn't make sense to waste space for the "alternative" unlock condition.
As far as I know the hash functions like SHA256 which are supported by Bitcoin for hashlocks are not totally quantum resistant. But the attacker would need to use Grover's algorithm (like when they "quantum mine" Bitcoin) which only provides a quadratic speedup to the brute force attack. In other words, such a secret hash should always be safe as long as Bitcoin addresses are safe, as far as I understand.
Excessively large quantum-resistant signatures don't make sense and the solution can't realy be to blow up block space by a similar factor.
These signatures could get a larger witness discount, but of course they would impact on the bandwidth requirements of Bitcoin full nodes. It's possible though that at the moment quantum computers become a problem, the bandwidth cost for SPHINCS+ signatures could be smaller than a ECDSA signature was in the early 2010s due to technological progress.