Written in VB5. Or in C, but we're not sure where to find the source. Or expecting to be compiled by a 16-bit compiler and run in a DOS box. Or written in some off-brand interpreted language, and the interpreter only runs on x86. Or...

Finding the source isn't free. Finding the archived compiler isn't free. Finding a machine that still can run the compiler isn't free. Re-writing the app isn't free.

Doesn't dynamic binary translation cover these cases? It can't be that performance sensitive if it's written it VB5 and running on modern hardware.

It might. But if you've got a VB5 program that you're still running, are you the kind of person who knows about binary translation? Or do you just say "I'd better keep buying x86 and running Windows forever"?

At the low level you don't know what instruction sets are. At medium to high level you know that despite the instruction set, old non-intensive programs will work fine. I think the range where you're spooked by the instruction set is pretty narrow.

VB6 is still officially under support in Windows Server 2019.

More like their infrastructure is dependent on old versions of tools that they don't want to upgrade, can't build, and only work on x86. Hugely common.