Either you're writing embedded firmware and know exactly what core you're using, or you're writing an application that runs in an operating system and that system has a minimum ABI like RVA20 or whatever.

It's very common for embedded teams these days to support a diverse set of cores with a shared codebase, depending on the specific requirements of different products/systems. SoC vendors will often change cores between versions or product lines, and I might need performance in this one system vs specific interfaces in another. So even if I know what core I'm using today, I don't know what core I'll be using in a year or five. I may also be writing a library or other reusable component and have no idea what core will run things today.

    Array accesses take an extra instruction? Either you're in a tight loop walking a tiny array and you don't do the full offset calculation per step, or you're walking over an array in RAM and you're bottlenecked by the memory bus.

Let's take the bitfield instructions the author complains about for similar reasons. If bfi/bfx takes multiple instructions, optimal structure packing isn't necessarily a win for performance or memory usage. The programmer needs to trade off how often the structure is instantiated vs accessed. Even they can make the right decision today, it might not be the right decision tomorrow. And if they get it wrong, that might not be apparent until later (when it will be somewhat obscured in superficial memory usage analysis). Or the ISA can get it right the first time and also make things easier for compilers/humans in the process.

    "Who can predict how their binary will act when a floating point store silently becomes a double-register move or a jump instruction, or vice-versa?" - THIS DOES NOT HAPPEN IN PRACTICE.

I can easily imagine this happening. When you change embedded platforms, the typical approach is to take the existing system and compile it for the new platform without carefully revisiting every decision made in the old system. If one of your vendor blobs was specified for the old system and the new system is "similar", you'll just link it in and see what happens. The metadata in the blob will hopefully catch the issue at link time, but it was an avoidable error.