If there would be a way to disable DES3 for this purpose in Thunderbird it would probably be a note on the bug report about it, which isn't. But instead of crying about the insecurity of 3DES let's look at how insecure it is in reality when used together with S/MIME.
The prominent attack against 3DES and other 64-bit block ciphers (like Blowfish) which led to treating these ciphers as insecure is Sweet32. This attack is based on the idea that one can decode part of the traffic provided that the content (plain text) of two blocks is the same or that part of the content is known AND that Ci (derived from IV and previous data in CBC is the same.
This condition is not unlikely with HTTPS traffic because of the properties of the HTTP protocol: a new request and response header will always cause a new encryption block to be started and the request and response will often be the same if the same resource is requested. Thus the weakness in the short block size combined with the properties of HTTP made it practically possible to extracts some secrets (like session cookies) out of the traffic. In experiments this was reached after about 600 GB of traffic but if we deal only with repeating always the same block of data it might be possible with 32 GB. Note that these 600 GB must be done inside the same TLS session, i.e. the same key must be used for all of this traffic.
From this can be seen that this attacks works only if the same key is used for a very large amount of data where a major part of the data repeats again and again so that in a large part of the input data the plain text content of the 64-bit blocks is the same. While such conditions can be created with HTTPS traffic it is highly unlikely to get this condition with mails: While one could imagine mails where the content of a attachments repeats again and again it is unlikely that enough input data for the attack are available since the size of emails is usually only a few MB and not lots of GB as needed for the attack.