Any language where the default equality comparison operator is *true* given two string-type variables with values "0E54321" and "0E12345" is not a cryptographically secure language. In fact there is a nonzero chance of the default equality operator returning true between two different MD5 or SHA256 hashes if they happen to fall into a hexadecimal form that is all digits except for one E or F.
Technically, that (in itself) doesn't necessarily mean that the built-in cryptography nor the language itself are inherently insecure. In theory, that is, provided you understand the language and use it correctly.
And that's the problem. Because in practice, PHP's design philosophy of trying to be clever- often too clever by half- when it comes to comparisons, equality, automatic coercion, data types, etc. etc. too often gives unpredictable and unexpected results from people who weren't aware of that behaviour.
You absolutely do *not* want any risk of this happening when you're designing a system that has to be secure. You want boringly explicit and utterly predictable data and type handling.
My prediction is that far, *far* more security holes will be down to bugs caused by unforeseen subtle aspects- i.e. pitfalls- of PHP's type handling and equality behaviour (etc.) in the apps using it rather than bugs in the cryptographic module itself.
PHP being a language more favoured by inexperienced users, this is likely to be made far worse. Expect lots of newbies with misplaced confidence designing what they think are "secure" apps that are in fact full of holes- either because they've misused or misunderstood the cryptographic module, or because they've overlooked some basic aspect of computer security elsewhere (e.g. failure to parse input securely) that makes the use of cryptography irrelevant.
And those are the sorts of mistakes newbies would make when using any language- with PHP's language design issues on top of that, it has the potential to be far worse.
So, yeah. I trust that the module will be secure. The main problems- I guarantee- will be caused by caused by overlooked (or not known about) aspects of PHP's too-clever-by-half data handling (in client apps using it) leading to exploitable holes, and by the fact that too many of PHP's newbie-skewing userbase will overconfidently assume it makes their apps foolproof while using it incorrectly and ignoring security holes elsewhere that make it redundant.