On the upside msvbvm60.dll is still shipped with Windows 10 and 11, so a lot of VB6 apps will still just 'run'.
Sure, the compiled apps still run fine, so at this point developer experience suffers a lot more compared to user experience and some users don't understand how much harder every day it is to work on VB6 codebases. (It's a bit of a horror hidden from users.)
The VB6 IDE predates a lot of modern code navigation tools.
The VB6 IDE predates common deployment of the mouse scroll wheel and scroll wheel support is provided by a cranky extension to the IDE that stutters awfully.
I repeat: Scroll wheel support is broken by default in VB6 and there's an extension you can find on the web to install (if you can malware scan it and get it across your network isolation boundary to your XP VM) and it's still awful. Imagine trying to read thousands of lines ancient code without scroll wheel support. Might as well be on papyrus scrolls.
The last version of git that supported XP is now pretty ancient and showing its age.
Good luck setting up an XP build agent for VB6 IDE CI. Which it never supported anyway (the IDE never had a good CLI build tool).
Developer experience of maintaining VB6 IDE apps in 2022 is pretty horrible and morale destroying.
I imagine that's a problem many projects would face trying to use the RAD Basic IDE, too and I don't think it's possible for it to be "no migration", because there will be components that won't work, won't relicense, etc.
Unfortunately the biggest challenge will be third party components. I work with clients who want to migrate VB6 on a daily basis and I don't remember the last time I saw an application without multiple third party libraries. Many of these can no longer be installed in new versions of Windows and so clients are stuck on Windows XP/7 (Even though you can have VB6 installed on W11).
I think you just answered your own question.