The issue here isn't implementation but rather the lack of a standard for SSL DCC*. This has resulted in various clients implementing SSL DCC's using their own vision for how the public certificates should be traded and authenticated. If mIRC was to support SSL DCC it'd have to support each of these differing implementations or we'd end up with various requests and bug reports about how mIRC isn't able to successfully maintain a connection to a different client. To complicate matters even further, most implementations do not make it known *WHICH* implementation the client intends to use. CTCP versions cannot be trusted and the DCC messages do not contain unique fingerprints to identify the implementation used.
*: The link you posted doesn't even specify how a key exchange should function:
The external protocol is exactly the same but is built on top of a Secure Sockets Layer implementation (specifically OpenSSL). The connection will be encrypted with a private key algorithm after a public key handshake.
How does a user, wishing to host the DCC chat specify its certificate, signing authority, etc?
How should it work if the hosting user does not have a registered certificate?
Should self-signed certs be allowed, and if so, how are they to be negotiated?
These are questions that (1) need to be answered and (2) standardized otherwise mIRC will just be adding yet another SSL DCC implementation to an already crowded field.