This works brilliantly on 64 bit machines, but the resulting integer is too large for 32 bit computers.
Actually, 32 bit computers can handle 64 bit numbers just fine. OK, so 64 bit arithmetic might take a few extra clock cycles on a 32 bit machine, but this is unlikely to be significant. (Or even relevant ... in your use-case.) For instance, the x86 instruction sets have 64 bit arithmetic instructions.
Does that make this a bad idea?
Not for the reason you stated. It could be a bad idea for other reasons. (For instance, if there is more information that you can encode in 64 bits then your scheme breaks down.)
How common are 32 bit servers, and do we expect them to slowly disappear completely?
They are still common, and they are likely to continue indefinitely. If you don't actually need more than 2^30 of address space for an application, then 32 bit pointers occupy less memory than 64 bit pointers ... so a "small" model architecture is going to be more power efficient, etc.
I also agree with @DocBrown. Error numbers introduce all sorts of problems of their own ... including the tendency to display unintelligible sequences of digits to end users. The human friendly approach is a well named exception, and an intelligible / informative exception message.
The other observation is that your question shows the signs of "premature optimization". The chances are that the real impact on performance of your proposed optimization will be insignificant, and possibly even too small to measure in a real application running under realistic conditions.
The standard advice is to not waste your time on this kind of thing ... unless you have concrete evidence (from measuring your application) that 1) the effort of optimization is warranted, and 2) this particular bit of code has a significant impact on your application's overall performance.