Regarding the big-endian nature of it: kinda, but also kinda not. Network endianness is generally big, so it'd work well in those instance without needing to do any juggling.
Plus (speaking from experience many decades ago on the 68k) reading big-endian memory was so much easier that trying to decipher things in a hex editor on ix86. Though, granted, this is both apocryphal and a minor thing to worry about.
You'd be surprised how many workloads end up spending large amounts of time in memcmp / strcmp. The chief advantage of big-endianness is that a 64-bit read is already in the order necessary for strcmp or memcmp. This means you don't need specialized instructions for fast strcmp / memcmp. Though, I would guess in a pipelined implementation with good pre-fetch logic, you'll usually not pay any time penalty (and only a single instruction in size penalty) for a byte order swap instruction in the middle of strcmp / memcmp.
> No byte load/store until, uh, EV56(?).
I believe that you can blame a MIPS patent for that, IIRC.
> And it's big endian, which per se isn't wrong in any way, you'll just be dealing with endian bugs forever and ever
Actually, that was one of the biggest benefits to porting Linux to Alpha. A HUGE number of assumptions got cleaned up. I suspect the current ARM ports of Linux would be almost a decade behind without that.
That being said, I wonder if at this point all the low level software (kernels, toolchains etc.) have bitrotted to the point that you're not buying much, if anything, compared to using RISC-V.
And it's not like Alpha doesn't have those irritating ISA idiosyncrasies. E.g. the most crazily relaxed memory model known to man. No byte load/store until, uh, EV56(?). And it's big endian, which per se isn't wrong in any way, you'll just be dealing with endian bugs forever and ever when porting since the rest of the computing universe, for better or worse, has converged on little endian (x86, ARM, even Linux on OpenPOWER)