It is not Microsoft; no it is the current hardware stack, in the server arena you have multicore 64 bit OSs (I dare you to find a well supported 32 bit server box today). And now it is getting really hard to find a consumer box which is not multicore in some way, and it is getting harder and harder to find 32 bit consumer boxes (yes you can put a 32 bit OS on them but now you just killed the machines upgradability by limiting its memory address space).
While today no one can imagine why you would need more than 2GBs of RAM just wait sometime soon 8GBs in a consumer box will be the norm. Because of things like video play back and in home video editing will become a standard thing for people to do on their PC. This will drive the use of more and more CPUs; the kids who are learning how to use a computer today will probably not remember the days of single CPUs and how hard it was to create a 1 hour long YouTube video (though I do not think one exists yet but someday just wait it will). In order to be able to do this kind of work new technologies have to become available (and their are some happening but the field is very new).
Now as to the death of VB6 it can not take advantage of these new technologies because first it is a 32 bit system their is no 64 bit compiler so it has to run in an emulation layer (WOW64). This limits its usefulness on a 64 bit server because of the inherent limitations of WOW64, i.e.. can only run in a single process, may allow for a larger heap memory size but you need to recompile with options the VB6 compiler does and will not support, in IIS only 1 32 bit worker process is allowed (it is going to get rather crowded in there if you have a large number of legacy apps), and finally the ancient runtime does not support threading the way it really needs to in order to take full advantage of multiple CPUs. These issues are the death knell for VB6; believe me if you can please start migrating your classic VB apps now because in 2-3 years you will be hurting.
Until next time.
blair