If this article was written 10 years ago, more people would probably agree. But nowadays, its perfectly possible to have a setup where all your machines, from large servers, to laptops, to small embedded devices, are x86, or aarch64, or something like that, and no mixed architecture is present. There are other, possibly more glaring, issues with sharing software across very different setups: Memory requirements, assumptions about filesystem layout, assumptions about syscalls/capabilities, assumptions about security. The architecture is usually at most a cli switch in your build pipeline, all this other stuff isn't.
That said, if you use Rust, Zig, Java, C++ (with Zig C++, for example), C (with Zig CC), building N different binaries for different targets is a bash script with exactly N lines of code. Not sure that's all that hard.
> where [...] people haven't tried their software, software has architecture specific bugs
I have to agree with this, just from the projects I've been part of, reviewed and used in the past. This is not an ARM issue, its an issue of laziness. People are inherently lazy, and they will only build and test on what is convenient. x86 machine at home, x86 ci/cd server, ... guess what isn't being tested on? Non-x86. That said, there are not that many things that can go wrong on non-x86 in my experience. They're usually little endian, they usually have 32 or 64 bit pointers, sizes, etc., and if they don't, they're likely not magical either.
People who still write C code, but also don't know that they can't just use `char`, `int` and `long` to mean 8, 32, and 64 bit, are the only population that will have issues here. Sadly, that's a lot of people in my experience.
The real issue is everything else, like I said above (fs layout, security, assumptions about OS specific behavior, ...)