Implementing cryptographic algorithms securely is hard. I should know. Cryptographic algorithms concentrate secrets into keys, which thus are very valuable, and a lot of implementation-related leaks (e.g. small variations of execution time) can become disastrous when applied to cryptography.
There are ways to avoid such leaks, but they require care, a lot of trial-and-error, and, above all else, extensive knowledge of the low-level behaviour of the execution engine. As a rule, the farther you are from the hardware, the harder it gets to secure the code against side-channel attacks. PHP is much further from the metal than C code.
Now I don't say that it is not possible; for instance, a timing-attack resistant implementation of a cryptographic algorithm is quite possible in Java or .NET. So it should be doable in PHP as well. But, as usual, it will require a lot of external scrutiny to ascertain.
Remember that new is bad in cryptography; security is gained through prolonged exposure. For all its shortcomings, OpenSSL has had a lot of exposure over the years.
phpseclib is newer, and uses a "somewhat hostile" framework when it comes to side-channel leaks, so it is much too early to declare it fit for production.
I don't know what you mean by "X.509 problem". I mean, X.509 is a spawn of Hell; but I don't see how an implementation in PHP would fare better. The one good point of PHP here is that PHP has checks on array bounds, thus limiting the consequences of buffer overflows (application crash instead of actually overflowing the buffer); this matters for X.509 only because it seems that many people are incapable of implementing ASN.1 encoding/decoding properly, without tripping on these buffers. But apart from that, the complexity of X.509 is unchanged, whether it uses C or PHP.
The idea of rewriting everything from scratch, "for simplicity", arises regularly when talking about X.509. But the "problem" of X.509 is not that usual implementations are bad; it is that X.509 is inherently complex, because it tries to deal upfront with the complex issue of trust delegation (all competing solutions just try to side-step it); and X.509 (the standard) has accumulated a lot of legacy crud. Rewriting it from scratch won't make it simpler, unless you remove the parts of the standard which you don't like, in which case it will be simpler, but it won't work.