This does, however mean that

1. This depends on closed-source code (libhoudini is Intel code, and it's not open, last I heard). I guess it's not the first piece of closed-source code in Chromebooks, but it's a crucial piece.

2. This code is still not portable, it just runs on 2 archs, unless someone writes a libhoudini for all other archs as well.

What "other archs"? Android only supports 3 ARM architectures (all of them will load armeabi binaries), x86 and MIPS (with 0 MIPS devices or phones being on the market).

Chromebooks run only ARM or x86.

Again, this is an issue that's relevant to a tiny minority of the applications since vast majority do not ship native binaries.

Even if no official Android devices use MIPS today, that could change tomorrow. And there are lots of Android forks, I would be very surprised if none of them use MIPS.

I don't think it's a major blocker, qemu already let's you emulate any arch that you need. Replacing libhoudini with a qemu based version would likely be straightforward.