It is always possible to express spending conditions in their disjunctive normal form, that is as a top-level “OR” of each individual spending paths. Taproot allows for each spending path to be in its own leaf. It is correct to claim that doing so would be maximally private as it would reveal the strict minimum of information about the spending conditions that were available for this output.
But there are multiple dimensions to optimize for when compiling a spending policy to a Script. Besides privacy, there is efficiency. It is not correct to claim that it’s always more efficient to use one Taproot leaf per spending path, or to switch to P2WSH, than to use an OP_IF in a Taproot leaf. For instance, take a simple policy like “2 keys can always spend together, 2 other keys can always spend after either a week or past block 1’000’000”. A Taproot with two leaves would be more efficient in this case than one with three, or than using P2WSH. Of course the more spending paths you have, the bigger the gains compared to using P2WSH.
Furthermore this analysis ignores a third optimization dimension: the probability of each spending path. Smart contracts often have some paths that are used frequently and others that are rarely used. Taproot lets users place likely paths higher in the Merkle tree, making common spends cheaper while pushing extra cost onto uncommon ones. So comparing scripts in isolation is misleading: what matters is the expected usage pattern. A policy that looks more efficient under P2WSH assuming equal use of every path may still be more efficient in Taproot in practice. For some use cases, switching to Taproot could save kilobytes of onchain data a month!
In fact one spending path may be so likely as to be represented by the Taproot internal key. This would make spending more space efficient than any other (secure) output type available, while potentially still necessitating an OP_IF in one spending path deep down the Merkle tree. This feature of Taproot highlights yet another reason why P2WSH is not a replacement for Taproot. Users may rely in their Script on features which are exclusively available in Taproot, such as protocols leveraging Schnorr signatures.
Finally, Taproot usage comes with a preferable set of externalities for the network than P2WSH. For this usage, P2WSH imposes more burden on validating nodes than Taproot because its signature hashing is quadratic in the size of the witness script. In this regard, Taproot also enables optimizations that relieve burden on validating nodes (batch validation). Besides costs to validating nodes, Taproot also incentivizes to grow all outputs’ anonymity set by providing a way to optimize the space efficiency of some spending paths.
To conclude, whether an OP_IF in a Taproot leaf is preferable to alternatives depends on a number of factors. These factors are best assessed by the user, who is better positioned to understand their own circumstances and constraints. It would be dubious and presumptuous for anyone to claim to know them better on everyone else’s behalf. This is especially reckless in the context of a proposal to invalidate them, given that Bitcoin development has historically gone to great lengths to avoid proposing consensus changes that could confiscate some users’ funds that way.