PKCS#1 only defines two "old-style" paddings (aka "v1.5" because these were the two paddings defined in PKCS#1 v1.5, while more modern versions add other options, known as "OAEP" and "PSS"). These two paddings are the "type 1" and "type 2". There is no defined "type 0" padding; of course, any byte can conceptually have any value in the 0 to 255 range, but PKCS#1 defines only two paddings, not three or more.
The two paddings do not differ only by the "type byte" (of value 0x01 or 0x02). The subsequent bytes (the "PS" string) are very important for security. In the "type 1" padding, the "PS" string consists only of bytes of value 0xFF; it is fully deterministic. In the "type 2" padding, the "PS" string consists of random bytes (the bytes must not have value 0x00, but otherwise they must be generated randomly in the 0x01..0xFF range). They cannot be used interchangeably. The type 1 padding is for signature, the type 2 is for asymmetric encryption. If you use a type 2 padding for signatures, then you obtain a very weak signature scheme (because of the malleability inherent to modular exponentiations). If you use a type 1 padding for asymmetric encryption, then you obtain a weak encryption scheme (because of the determinism of type 1 padding, allowing a brute force attack on the plaintext).
The "BT" byte that identifies the padding type is there chiefly (and mostly) to make the two paddings unambiguously distinct. Otherwise, one would have to worry about attackers using a signature as an encrypted message or vice versa. Thus, the two paddings should have a distinct "BT" value; the PKCS#1 authors could have chosen the two values to be 0 and 1, or 1 and 2, or 17 and 42, or any other pair of distinct values; they chose 1 and 2. This is arbitrary.
In any case, the importance of the padding is not in the "BT" byte, but in the bytes that follow (the "PS" string). It is not recommended to use a "type 0" padding because there is no such thing as a type 0 padding.