I think the comparisons are much more apt than that. It's a set of interlocking 80/20 challenges. In both languages ~80% of the language stayed the same, the huge fights were over that remaining 20%. Similarly in both cases users themselves maybe only used 80% of the overall language capabilities but among users it was frequently a
different 80%, and one person's unused 20% was another person's critical "must have" deep in their 80%. That in particular is the 80/20 rule that affects what a developer might consider "minor tweaks".
Beyond that there are the exact same basic economic disincentives to migrate: large code bases have larger sunk costs, more friction, and less interest in migrating. It's the really large code bases that have the most reason to be disruptive in any migration.
In the VB6 to VB7 change, some could have just "re-test and do minor tweaks to existing code", even without the GUI converter helping you with all the Designer-generated metacode, had you been using VB best practices. There wasn't anything anywhere near as significant as say a massive change to default representation and syntax of strings (such as Python 3 switching to Unicode by default; VB6 at least came from Microsoft's UCS-2 era, which is also partly how so many of its programs have managed to survive in Enterprise this long). The problems were much more long delayed deprecations and a bit more forced handholding in project organization (classes existed in VB from the beginning, but so much VB was still global variables and disorganized global modules).
As someone involved in multiple migrations out of VB6 at this point in my career, second only to big Enterprise Sunk Costs reasons, I very much feel that project organization was the biggest reason codebases had to "start over". A large VB6 project built using almost nothing but global variables and global modules is a fun spaghetti ball to untangle back into some semblance of OOP. It wasn't anything syntactic or technical (otherwise presumably better migration tools could have been built if it were something mechanical like that).
Even the closest to a technical problem was essentially a universal one that applied somewhat similarly to Python 3 as it did to VB7: C/C++ FFI changed a great deal from ActiveX papering over COM's worst faults and VB pretending DLL calls were easy (and shuffling its DLL Hell under the carpet) to .NET's complicated COM relationship and P/Invoke system that more accurately reflect the FFI reality in Windows (versus VB bubblegum and lollipops). Even then, P/Invokes sure look a lot like VB<=6 FFI calls because they were clearly based on it. (There are also ways in .NET to pretend COM is friendlier than it is, themselves early VB inspired.) FFI can be assumed to be a challenge in just about any language upgrade/update/migration in the history of languages, and that's not entirely a backwards compatibility problem you can fix nor prevent in the language design. (Look at the native interfaces of any and every other language out there.)
(Sure, I've seen the laundry lists of complaints of things that weren't backwards compatible, but compared to the 80/20, it's absolutely fair to compare VB 6/7 and Python 2/3, and to admit there is no magic "right" solution in either case to avoid the migration hurdles both experienced.)
> The auto-converters were poor, mostly because GUI land doesn't map well to Web Land.
While there was a lesser used "webforms" converter, the major converter was direct GUI to GUI from VB6 to .NET 1.0 WinForms, very apples-to-apples, and it did a rather good job given what it had to work with (both the byzantine messes that were the average VB<=6 codebase and the young and not quite polished, but certainly capable in theory of everything previous VB did, .NET 1.0 WinForms). While with hindsight we mostly all agree "webforms" was a bad idea, it wasn't the emphasis in migration stories, and it certainly was never the only option (and where it was seen as the only option likely the local myopia of management that were the ones wanting the instant jump to Web Land "for cheap" in a migration to secure funds for said migration in the lands of sunk costs).