Backwards compatibility has limits. When a piece of software has been abandoned for 30 years, there is very little commercial value in supporting it. Apple, Google and even Linux are more aggressive in dropping support. It's only IBM on mainframes with multi million contracts that is really going for backwards compatibility at any cost.

On the other hand, I'd argue companies using 16-bit applications would be unwilling to upgrade to a 64-bit installation anyway. Microsoft decided it was better to push software developers to upgrade to Win32, given that 32-bit Windows already existed since 95.

By the time 64 bit Windows comes around the only stuff still running 16 bit is on machines that will never be updated. Embedded boxes in industrial machinery that is itself no longer supported, that sort of thing. No point making it work if nobody will ever update to it.

being able to transfer HANDLEs across the 16/32-bit boundary notably for COM/OLE integration becomes a lot more painful

Microsoft says at https://learn.microsoft.com/en-us/windows/win32/winprog64/ru...:

> Note that 64-bit Windows does not support running 16-bit Windows-based applications. The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data. Attempts to launch 16-bit applications fail with the following error: ERROR_BAD_EXE_FORMAT.

winevdm on Windows eschews that level of integration, but perhaps MS should have shipped WoW16 with limitations instead of nothing.