In VaultWiki 3 showthread.php links that pointed to wiki articles were already 301 (permanent) redirects to the showwiki.php script. Thus, any sophisticated crawlers or bookmarks should have never indexed the showthread.php version of the URL. Because VaultWiki 3 automatically replaced showthread.php links with their showwiki.php counterparts in the page output, it is also unlikely that users ever saw the original showthread.php link in order to copy-paste those somewhere.
The only exception is for wikis that existed before VaultWiki 3 was installed, where the wiki forum was converted to a VaultWiki 3 wiki forum at such time -- links that existed already may have used showthread.php versions. We do not handle this very small percentage of links.
For those fringe cases, you are talking about many years already that 301 redirects have been in place. Our general practice for a version 3 to 4 conversion has not been to give 301 redirects for anything except VaultWiki 3's showwiki.php (and this is only automatic in the vBulletin version).
--
Still, we have recently been considering other ways to redirect things, and other things that may need redirecting. For example, we are migrating our own (vBulletin CMS) News pages into VaultWiki and need to preserve whatever vBSEO did to those URLs, but those versions of the URLs are not stored in the database to capture easily during an import process. If I recall correctly, this is the only thing holding us back from a vBulletin CMS to VaultWiki 4 migration path.
Looking at the redirection scripts that are available for showthread.php in XenForo, it looks like they are designed to give up if a thread is not found. This doesn't work well when you are looking to have both a showthread.php handler for wiki URLs and one for standard XenForo URLs. There are a lot of things to consider for a showthread.php handler.