I agree with you (that it could be an important tool).
However I will say that the VB6->VB.Net transpiler which Microsoft produced (and clearly spent significant amounts of effort on) was pretty terrible. And that is one of the most "complete" transpilers I know of...
The problem is that for a transpiler to produce "good" output code it needs to have a deep understanding of both context but also intent. This is particularly important when converting from one language to another with slightly different underlying concepts (like VB5-6 Vs. VB.Net). Without that understanding it just produces spaghetti code, that will technically compile (*although often it didn't in the VB6->VB.net example) but is unmaintable.
I liken it to Microsoft Word's HTML engine. Word can produce websites, and those websites technically looked correct in most browsers, but they became an unmaintainable mess in the medium to long term. A lot of transpilers have the same issue.
The best thing I can say about transpilers is that they're very good for a starting point (assume 100% refactoring anyway) and converting simplistic data storage vehicles (e.g. classes with tons of constants).
There's also the problem of dealing with the standard library. Not everything has a directly equivalent function. So you'll make your app dependent on an obscure library based on another language's standard library.
More advanced transformers even handle direct transformation of library calls to "native" library calls in the target language. I think it's mostly things that try to take advantage of syntax that is already pretty similar - Processing.js transforming from Java to JavaScript, for example, that decide it would be easier to do a relatively simple syntax transformation and then implement some sort of wrapper for function calls (as you describe) than to do a potentially more in depth and complicated transformation.
The migration tool that came with Visual Studio 2002-2008 is a licensed product from a third party company (a "lite" version actually). The tool was demonstrated (and this fact mentioned) in some Channel9 videos (Microsoft website) about ten years ago.
Word and Frontpage used the same COM code based on trident (IE). Frontpage is dead, the successor Expression Web used a new HTML engine and is dead as well. The second Frontpage successor that still used the trident engine was Sharepoint Designer 2007. Version 2010+ lacks most layout features as the old Frontpage based code generated ugly HTML4. Word 2010 (and probably also 2013) still generates (ugly) HTML4 with inlined VML (graphics, WordArt) based on older trident.
And there is also InfoPath 2003-2013 (dead as of 2014) that is based on a modified Frontpage/trident code. It uses CAB based archive format to store XML and XSD files that resemble the user defined form data. The InfoPath WebForms are generated server side based on the XML stylesheet and XML data. Microsoft is working on a successor to InfoPath merged with other Office products and mobile compatible.
This could be a crucial tool for companies backporting legacy PHP code into a new language.