This upside-down-world is common with process error returns. The shell variable $? reports the return value of the previous program to execute from the shell, so it is easy to tell if a program succeeds or fails:

$ false ; echo  true ; echo $?
0

This was chosen because there is a single case where a program succeeds but there could be dozens of reasons why a program fails -- by allowing there to be many different failure error codes, a program can determine why another program failed without having to parse output.

A concrete example is the aa-status program supplied with the AppArmor mandatory access control tool:

   Upon exiting, aa-status will set its return value to the
   following values:

   0   if apparmor is enabled and policy is loaded.

   1   if apparmor is not enabled/loaded.

   2   if apparmor is enabled but no policy is loaded.

   3   if the apparmor control files aren't available under
       /sys/kernel/security/.

   4   if the user running the script doesn't have enough
       privileges to read the apparmor control files.

(I'm sure there are more widely-spread programs with this behavior, but I know this one well. :)

Another way to think about it is that main() returns an error code. Zero means "no error".

You can actually see the value that main returns. If your program is named "test", use this command to run it:

./test ; echo $?

and the shell will print out the value your main returned.

Because the math works.

FALSE OR TRUE is TRUE, because 0 | 1 is 1.

... insert many other examples here.

Traditionally, C programs have conditions like

if (someFunctionReturningANumber())

rather than

if (someFunctionReturningANumber() != 0)

because the concept of zero being equivalent to false is well-understood.

Because the actual register cannot store a bit, and the register has no type,

You are probably thinking about a general purpose register. However, CPUs typically also have flags to store certain results, and those flags are typically one bit containing a true/false value. Many CPU architectures have something like a CMP (compare) instruction, which can compare two values for equality, and which stores the result in one of those flags. Some CPUs allow those flags to be accessed directly, some only indirecly (like with JE/JNE (jump if equal/not equal) instructions), and some present a collection of flags as a single status register. Still, you can think of the flag as a single boolean register.

It's also not right to say that register don't have a type. You typically have different types of registers, some for integers, some for floating points. In hardware, there is typically a set of registers that are all 32 or 64 bits, but the instruction set might expose logical registers that are 8 or 16 bits wide. At the hardware level there are also no ones and zeroes, it's some amount of charge or voltage, or the absence of it, and it doesn't even have to be that a high voltage means a 1.

Mathematics usually uses 0 to represent false and 1 to represent true

I think it's computer science that does that, not mathematics.

Some mathematicians believe that 0 and -1 should be used from the perspective of truth tables

Some operations on booleans have an equivalent in operations on integers. For example, if you use 0 for false and 1 for true, then a logical AND is equivalent to multiplication of those integer values. You can then also see that this no longer works if you use 0 for true and 1 for false.

When working with registers of a fixed width, you are working in a ring with modular arithmetic, and usually signed numbers are stored in two's complement. That means -1 is equivalent to all bits in that register being 1. This can make some things easier, for example in the following piece of C code:

bool a = …;
int x = 123;
int y = a ? x : 0;

The compiler could then replace the conditional expression with a bitwise AND operation:

int y = x & (int)a;

Which could result in much faster assembly being generated. However, since using just 1 and 0 for true and false is so common, most CPUs provide instructions to handle that as fast as storing booleans as -1 and 0 would.

Also, note that in C and languages that use the same ABI, 0 is false but when converting an int or other similar type to bool, any non-zero value is considered true. And while the ABI says that a boolean is stored or passed as a parameter, the value should be exactly 1 or 0, the compiler is allowed to do anything it wants behind the scenes as long as the observable end result is the same as what the language specification says. So it might actually store true as a non-zero value other than 1 if that is more expedient and nothing would break.

The solution adopted by the shell is 0 to represent true and other values ​​to represent false

Not exactly; the result of a command is not a boolean, it is an error code, where 0 means no error. The same goes for errno.

Mainstream FFIs all default 0 to false

Because C defined false to be zero, and most FFIs use C's ABI.

CPU initialization is all 0 initialization,

Not necessarily, and especially not the memory. A BIOS or operating system's first task is usually to zero all memory. The CPU has defined reset values for some of the registers, and some of those reset values might not be zero. When a program is started by the operating system, it's also not the case that all registers are zero.

What is true is that often the CPU provides a fast way to set a register to zero, either by having specific instructions for that or by having a special register that is always zero, and that you can copy into other registers. And even if there is nothing explicit, you can almost always XOR a register with itself.