There was a topic about it: https://bitcointalk.org/index.php?topic=5220520.0

In general, there was some drama, regarding activation of OP_CTV, and it simply failed. If it wouldn't fail, then we could have OP_CTV first, and Taproot later.

However, it is, what it is: soft-forks are difficult to deploy properly. We don't even have a clear consensus, how the next soft-fork should be deployed, whatever it will be. Which leads some people to create their proposals in a no-fork way, because then, it has a higher chance of succeeding.

And also, OP_CAT is more generic. Why this is important? Because if you deploy for example OP_CTV, and you find out later, that "hey, we forgot about use case X", then it will be very difficult to activate yet another soft-fork, to add this functionality. However, with OP_CAT, it is more likely to cover everything (or even more than needed).

For that reason, there would be quite strict limits, on top of OP_CAT. One example is 520 byte limit (it is unlikely, that OP_CAT will be deployed with a higher limit than that, as long as it is the maximum size of things, which can be pushed on a stack). Another example is 520-bit limit (65 bytes), which would be enough to cover a single signature.

So, if OP_CAT enthusiasts will spam too much, then we could go with 65-byte limit, instead of 520-byte limit for OP_CAT.

And also, if there will be no consensus for OP_CAT, then there is still OP_CHECKSIGFROMSTACK, which is more likely to be deployed, than OP_CTV, and which can do the same things (and a little bit more than that).