I can understand requiring consumer based systems to offer x86 emulation like Mac M1s. This is because consumers tend to be less sophisticated, expect their old applications to run like before etc. etc.
This product is squarely positioned as a server product. I don't see the need to have to offer performant x86 emulation like Mac M1 does (you could run QEMU if you wanted though but that's going to slowish).
You have all the major programming languages, HTTP servers, databases, OSes running on ARM Linux. If you're buying an Ampere server it would sure be a waste to expect then to run x86 in emulation!
Hardware with x86 compatibility is only relevant if for some reason you are stuck with x86-only software somewhere in your stack. Or you have specialized hardware that you can't run on another platform for some reason. But I'd argue most new applications aren't dependant on x86: most modern and relevant programming language have production-grade compilers and runtime environments for ARM and increasingly also for RISC-V.
Emulation is possible, and now even easy. Windows has a built-in Windows on ARM (WoA) feature, and Linux can do something similar with QEMU application-based emulation (including stubbing out calls to dynamically linked libraries with calls to native ones).
This is in addition to the fact that a lot of server-based code runs as an interpreted/JIT language, or a bytecode VM like Java or .NET.
This product is squarely positioned as a server product. I don't see the need to have to offer performant x86 emulation like Mac M1 does (you could run QEMU if you wanted though but that's going to slowish).
You have all the major programming languages, HTTP servers, databases, OSes running on ARM Linux. If you're buying an Ampere server it would sure be a waste to expect then to run x86 in emulation!