Running another uarch is a whole new level of complexity vs just running on a different OS but with the same uarch, especially if concurrency is involved because translating from one instruction set to another can break atomicity assumptions that concurrency depends on to maintain coherency. You'd need to do thorough analysis of the code to determine where special care is needed, and even then, it won't be trivial setting it up in a way that avoids deadlock because you have to understand what the threads are doing before you can say if it's safe for one thread to wait for another (since they could end up waiting for each other).

Whereas running code meant for a different OS just requires implementing that OS' API (and behaviour, possibly including undocumented behaviour some code relies on, which can vary from application to application, hence windows compatibility modes where they add a translation layer themselves). Not saying this is trivial, but compared to the above problem, it kinda is.

Not that ARM support is impossible, just if they manage that, it will be proclaimed loudly, not something that requires digging. If they don't say it supports ARM, just assume it doesn't.