But there's not a huge market (and therefore, FOSS dev time spent on it) for emulating AArch64 on x86 the way there is x86 on AArch64, so if your options are to build your own AArch64 emulation for x86 (or drop a fortune into an existing FOSS option), or building something based on AArch64 and using the existing x86 emulation implementations, one of these has much more predictable costs and outcomes today.
If an ARM device both suits the goals and has lower risk, there's little upside other than forcing the project to exist.
And since there's very few pieces of AArch64-exclusive software that Valve is trying to support, that's not a goal that benefits the project.
(If I were guessing without doing much research, Switch emulators might be the largest investment of effort in open source on x86 systems running AArch64 things performantly, but that's certainly not a market segment Valve is targeting, so...)
To have flexibility and not being tied to CPU choice due to simply lacking software side. Besides, such kind of project would be beneficial to more scenarios than their immediate need.
They didn't need to back a bunch of projects they backed (radv / aco are a big example where you could claim there was redundancy so they weren't strictly necessary), but results paid off even to the point where AMD is dropping their amdvlk in favor of using radv/aco.
They didn't need to strictly speaking back zink either (OpenGL on Vulkan), but they decided to and it gives them a long term ability to have OpenGL even if native drivers will be gone, as well as an upside of bringing up OpenGL on any Vulkan available target out of the box.
It's just something in their style to do when there seems to be an obvious gap.
It's in their style to do when they think there's a benefit to them from it, short or long term.
I'm not claiming they're not beneficial or acting in bad faith, but their past contributions are "making enormous improvements in the ecosystem when they think this is the best option for them" - things like radv+aco you could see as "we looked at AMD's solution for this and decided it was lower risk to build a better one ourselves" - and I can't really argue with their logic, even if AMD hadn't given up and gone for it, they have a history of switching solutions every so often and then god help you if you built around the old one.
Zink makes sense because it closes a unique gap (supporting older games if OpenGL support sunsets) in their platform, not just for its own sake.
AArch64 emulation on x86 is useful, but doesn't fill such a gap for them, IMO. Nothing is uniquely targeting AArch64 in the library of things they want to support on Steam platforms except non-game software targeting only macOS/AArch64.
I would predict, since they seem to be adding some level of Steam game support for handling Android games [1] [2], that you might see them financing such a thing in the next couple years if there's enough things exclusively targeting Android or AArch64 that they want to de-risk people complaining they can no longer play them in 5-10 years.
