Theoretically, X.509 chains are unlimited in length. The Basic Constraints extension can apply a per-chain limit; this is used mostly for CA that agree to issue a sub-CA certificate but want to constraint that sub-CA to issue only end-entity certificates.
Implementations may have limitations. In fact, with some carefully crafted certificates, one can make a path-building application explore n! potential paths of depth n, and since factorials go up pretty fast, this can lead to huge denial-of-service attacks. Correspondingly, implementations tend to impose a relatively low maximum length (I know I used '8' for my own implementations).
In broad conceptual terms, trusts dilutes pretty fast upon delegation. When a CA issues a certificate to a sub-CA, it not only asserts that the sub-CA public key is owned by that sub-CA, but it also empowers it to perform that kind of verification on behalf of the parent CA. When a CA issues a certificate for an end-entity, it checks its identity; when it issues a certificate to a sub-CA, it also needs to make sure that the sub-CA won't be gullible. With a third level, the CA must ensure that the sub-CA is not gullible and won't issue a certificate to a gullible sub-sub-CA.
So the reflex would be to try to keep chains short rather than long.
Be wary of the "single point of failure" expression. It normally applies to operational continuity. Here, we are talking about security: a single rogue CA compromises security, regardless of how many other paths you create. This goes somehow in reverse with the SPOF rule: you avoid SPOF by adding redundancy, but in the case of certification, any involved CA is by nature able to compromise things -- the more CA you add in the mix, the more vulnerable you get.