That's it. What do you think is bad here ?

Thanks for asking.

1. New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.

RDTS only allows one OP_RETURN output, so that would mean that any systems that embed more than 80 bytes of data in outputs would be forced to use unspendable payment outputs for anything in excess of 80 bytes (like the example that started this debate). Also, what if we want to introduce a PQ-safe output scheme next year that needs more than 34 bytes in its output script?

2. OP_PUSHDATA* payloads and script argument witness items exceeding 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.

Seems pointless for reducing data insertion as stack items are already limited to 520 bytes and multiple 256-byte pushes would still be allowed, otoh, such a low limit would probably be incompatible with some future soft forks, e.g., PQ-signature schemes which might need drastically larger public keys and signatures.

3. Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.)

Breaks our upgrade hooks for introducing new output types, e.g., if the P2MR proposal were to gain steam in the next ~14 months.

4. Witness stacks with a Taproot annex are invalid.

Breaks another upgrade hook, and is unused.

5. Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid.

It can only have 128 leaves if all of them are at a depth of 7, which makes the control block 258 bytes. Most P2TR script trees are unbalanced binary trees (think Huffman trees) to make the more likely leaf scripts have smaller control blocks.
So, we don’t need OP_IF, because we can split up scripts into multiple leaves, but then we also limit script trees to a depth of 7? Seems unnecessary and dumb, but most people can probably make due with depth 7. This might be the least offensive rule, yet.

6. Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid.

Breaks more upgrade hooks, in a time when some covenant proposals actually had been gaining a little momentum.

7. Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.

Making OP_IF invalid is an absolute no-go. Beyond if(…) being the most basic conditional statement in every programming language under the sun, there are a number of projects that have rolled out Miniscript support in mainnet, and Miniscript is known to generate leaf scripts with OP_IF in some circumstances. Since script leaves do not become visible unless used, and most P2TR outputs with more complex spending conditions have an “everyone signs” keypath fallback, it cannot be ruled out that users have deployed wallet patterns based on OP_IF to mainnet. Since we cannot determine whether who such people might be and therefore cannot ensure that all such people are aware, have updated their software, and have migrated away from such wallet patterns, and it generally cannot be prevented that senders reuse past scripts that used such a pattern, this must be considered to break user space on principle. RDTS proponents have argued that this is acceptable, Bitcoin protocol designers generally seem to consider this indefensible.

Some further thoughts:

1. The above is just taking the proposed consensus rules at face value and assuming the soft fork is actually temporary. However, when asked how proponents expect to proceed after BIP110 expires, they frequently float that once RDTS is activated, they would lobby for the rules to become permanent. That would obviously be disastrous, because it would remove almost all upgrade hooks protocol developers have labored to create in the past dozen years and would permanently disenfranchise any affected users.
2. 55% activation threshold is completely irresponsible.
3. Going for mandatory activation on a first activation attempt, especially for an idea that is so obviously controversial, forces a game of chicken that undermines any potential for charitable interpretation.

The entire soft fork is based on only processing the first part of what protocol developers have been telling filter proponents for years: policy can be undermined by a tolerant minority, so it is infeasible to establish more strict policies against collaborating senders and miners—transaction patterns can only be effectively forbidden at the consensus level. However, consensus changes move slowly enough that data enthusiasts can easily preempt new consensus rules if their fad hasn’t jumped the shark by itself by then.

RDTS forbids inscriptions and large OP_RETURNs. Meanwhile, inscriptions have diminished to a minuscule portion of blockspace and large OP_RETURNs are basically non-existent, while still almost have the blockspace is going towards other NFT transactions (now based on Runes which RDTS will accept). Numerous ways to embed data even under RDTS rules have been demonstrated.

When someone proposes a consensus change, it is on them to convince the ecosystem that the benefits are worth the cost. The default position is that the status quo is maintained. This consensus change proposal is poorly motivated, recklessly designed, and irresponsibly championed. The doubtful benefits drastically fall short of the downsides and costs.