Such defensive/portability measure could indeed be useful in some cases but there’s a continuous spectrum that goes from non-sense to absolutely necessary.
Whenever you write low level code, you must assume something about the hardware. And we are indeed talking about low level code here since otherwise basically everything can be simulated. 2s complement arithmetics can certainly be implemented on archs that natively support 1s complement and vise versa. It may not be as efficient but it should work.
Just because something “could” happen is never a good argument for anything. You always need to consider the probability, the cost and the benefit of it. There are a huge number of assumptions we make about OS, arch, uarch, endianess, bit representation of integer, floating point, pointers, memory model, thread model, etc. There is only so much assumption you can give up before you’ll literally not be able to write any code. The solution/defensive measure for each one have to be considered separately and ranges from making strong assumption, to writing multiple versions of code, to using a generic abstraction (i.e. weaker assumption) or even cross compiling (targetting accelerator for example). It is a valid point to bring up about supporting hardware with different integer representation but you just can’t ignore the current environment when talking about it. I’m sorry but your favorate CPU from the 70s might never be supported by julia and that’s at least partially because very few people miss them… (which doesn’t necessarily because it’s bad, but that it doesn’t fit in the world anymore…)
Now for this particular case, there’s basically no argument to be made about hardware. That’s not to say such hardware will never ever exist again but since basically nothing exist in a vacuum, unless some major discovery is made, no one is ever going to make a non-2’s complement comercial hardware in the foreseeable future. The investment to bring up such an architecture would be huge given how often such assumption is made in code these days. If for some reason it really happens, with all the dependencies fixed, fixing julia would be easy compared to the work done before us. (Note that this is basically the same argument that justify us making as much assumptions as our dependencies)
That is not to say one is encouraged to use bit operation on integers and especially not floating points. There are still different representation of numbers (arbitray length/precision, decimal numbers) so if something can be done with arithmetic operation just as efficient it is certainly preferred to do that since the code would be more generic and the algorithm would be more easily applied to a different type. However, for a specialization that is operating only on known type and if using bit operation simplify the code, then there’s no reason not to use it.