Look at the total upper memory on the 6.22 machine, it has approx. 32KB less. It doesn't have enough free space to hold MSCDEX, which is why it's in conventional memory instead.

Different machines might have different ROMs installed at different locations in upper memory, thus fragmenting the space and making it more difficult to load drivers into high mem, especially the big ones like SmartDrv and MSCDEX.

Tinker a bit with the BIOS settings to reduce any unneeded devices/shadowing/...etc. A more scientific approach would be to use a tool to show the memory layout and who is taking what. SysInfo has such a tool.
Third, try reordering driver loading to make the big ones load first. Finally, you can try MEMMAKER to figure out the best layout for you. It's not always successful, but worth a try.

Type MSD and then select "Memory" to see the available upper ranges.

I had encountered a similar mystery back in 1995 when I bought my first Pentium 120 MHz with 16MB RAM: the UMB on the new computer was much smaller than that of my 80386 with 4MB RAM, even with almost identical CONFIG.SYS settings. I tried to boot both computers with the same DOS 6.2 floppy and remarked all CD-ROM, sound cards, and even mice drivers in order to eliminate or minimize all possible variables, leaving nothing but HIMEM.SYS, EMM386.EXE, and SMARTDRV.EXE, but the results were the same.

I posted the question to a Usenet newsgroup (possibly alt.sys.pc-clone.dell) and received a reply explaining that was "because of chipset design" and I couldn't do anything about it. No details provided (I couldn't understand it even if there were). The motherboard was a Dell Dimension XPS based on Intel Advanced/CM with 430FX chipset. I'm sure my 386, 486, and 430TX motherboards had no such problem.

So while I'm not an 86Box user I'd make a wild guess that chipset emulation might have caused the difference as 430FX was a popular chipset in early Pentium era. I might be able to reenact the situation on that computer (still alive and kicking) but would take a while as the computer isn't with me but my parents, and I have to remember to bring along a DOS 6.2 startup floppy on my next visit. 😅

The i430fx motherboard might use more UMB blocks at the top of the range to unpack the BIOS ROM into? It depends on the BIOS used, though. The bottom of the range (segment C000 onwards) contains any option ROMs used by hardware cards (starting with video, possibly also a network card ROM), beginning each ROM rounded up to the earliest 2K address. Anything that's left is where DOS UMB blocks and EMS page frames(if used, although might be in high memory since it's mapped by the CPU's paging unit, which it usually is. But that still makes the virtual UMB blocks (usually at segment E000 for 64K, so E000-F000, where the BIOS usually starts)) reside. Afaik some BIOS ROMs are 128K, so they start af E000, so EMS needs to move to D000 instead. Anything remaining (C600 or C800(video ROM) with other ROMs, then available till D000(128K Mobo BIOS with EMS)/E000(64K Mobo BIOS with EMS or 128K Mobo BIOS)/F000(64 Mobo BIOS w/o EMS) are your UMBs where application loads, perhaps also at segment FFFF for addresses 100000+ (HMA), where things are usually loaded (DOS itself at least, the 64K-16 bytes memory where LH and DEVICEHIGH etc load, as wel as DOS=HIGH).

It's possible to use Helix Multimedia Cloaking as a workaround here, by the way.
It has custom versions of SmartDrive, MSCDEX and Mouse that run in Extended Memory.