(A 2-of-2, 3-of-3, n-of-n will be referred to as a multisig scheme and a 1-of-2, 2-of-3, k-of-n where
k < n will be referred to as a threshold scheme)
The most significant incentives for using Taproot (in terms of reducing transaction fees) exist for those who are using either multisignature/threshold schemes (the larger the multisig the larger the incentive) or complex scripts (that may also include various multisignature/threshold schemes within them).
There are various MuSig schemes that are at different levels of maturity. Classic MuSig (for multisignature, not threshold) has gone through multiple iterations and is at a point where its design is unlikely to be revised significantly. It is not yet used in production but it is plausible that it could be if and when Taproot is activated on mainnet.
Murch has an excellent Medium post and a StackExchange answer describing the fee savings from using Taproot and MuSig for a 2-of-3 threshold signature use case. There is not a threshold MuSig scheme that is ready to be used in production (at the time of writing, October 2020) but using multisig MuSig you can get up to 45% fee savings in comparison to using P2WSH. You do this by setting up your Taproot key path spend as a 2-of-2 MuSig (with only one combined key going onchain if it is used) and two alternative 2-of-2 MuSig script path spends as separate leaves in the Taptree. (You are effectively turning a 2-of-3 threshold into three alternative 2-of-2 MuSigs. This is the most efficient approach because for each MuSig only one key and one signature goes onchain when a MuSig scheme is used to spend.)
Assuming that you will use the key path spend the majority of the time (i.e. you can identify two of the three keys that will be used the majority of the time) the fee savings really are significant. These incentives are likely to drive some of the early adoption of Taproot.
For more details on the current state of Taproot multisignature and threshold schemes see this presentation from Tim Ruffing at London Bitcoin Devs (June 2020).
Thanks to Pieter Wuille and Murch for answering my questions on IRC. Any errors are my own.